Курсы Университета Беркли: http://webcast.berkeley.edu/series.html
Из прослушанных особо понравились:
CS162 Operating Systems Programming
C10 Physics for Future Presidents
А те, кто уже зарегистрировался на БитСпайдер могут сразу раздавать инвайты? Так хочется получить инвайт, но почему-то мне кажеться, что allein уже все раздал.
Странно, а я всегда считал, что распределенные VCS плохи для работы с бинарными файлами, поскольку требут при клонировании копирования всей истории. При работе с исходнгиками в репозитории храняться сжатые дельты, поэтому он практически не растет. А для бинарных файлов дельты хранить не получиться. В чем тут отличие Mercurial от Git?
К сожалению, как раз ощущение «не может быть, что оно так просто само все объединило» я рационально подкрепить не могу. Мы с сотрудником неделю работали, каждый над своим клоном, а потом я в GUI нажал на «Pull», «Merge», в визарде понажимал несколько раз на «OK» и вуаля — у меня закомиченная объединенная версия. И субъективно это воспринялось как: «Так, надо все еще раз проверить».
Это субъективное, конечно, ощущение, но вознило почти у всех наших сотрудников, когда они по-одному переходили на hg.
Я совершенно не утверждаю, что SVN хуже объединяет. Но, например, в hg нет ключа '--reintegrate'. Он будет объединять ветки в любую сторону, а потом обратно и везде с минимальным участием человека в процессе.
Кстати, 'hg share' (с включенным плагином) позволяет создать альтернативную рабочую папку (желательно в рамках одного компьютера) и экономит место. Вы комитете в одной папке, а в другой дерево истории тоже обновляется. Так можно иметь один репозиторий и одновременно несколько последних версий разных веток.
А как вы справляетесь с тем, что 'hg branches' выдает засоренный список веток, позвольте полюбопытствовать?
По поводу неименованых бренчей я основывался тоже на документации, см. The flow of changes—big picture vs. little. Под неименованными ветками в этом разделе подразумевается короткоживущие ветки, которым специальные имена не дают и их изолируют в отдельном клоне репозитория.
Но, это терминологический спор, сути все равно не меняет. Вы тоже правы.
Я при выборе VCS остановился на Mercurial по следующим, возможно субъективным, причинам:
1. В Git с поддержкой Windows довольно плохо.
2. К Mercurial есть плагин позволяющий хранить временные штемпели отдельных файлов — специфика конкретного проекта.
3. Ревизии Git идентифицируются хэш-идентификаторам, что не удобно для кратковременного запоминания (пусть даже и части id). В Меркуриале идентификатор состоит из локального номера и глобального идентификатора (типа 143:ab46778a...), и в 99% случаях для работы с репозиторием достаточно запоминать номера.
Сравните, git diff as5675ff:cfg7с261
и hg diff 100:145
А так, оба инструмента очень хороши.
Это специфика Mercurial (в отличе от Git). Каждый клон является «неименованной веткой» (unnamed branch). Именованые ветки для разработки конкретной функциональности в Mercurial создавать не удобно, поскольку имя такой ветки будет существавать всегда. Именованая ветка в mercurial создается для постоянных веток (типа «stable», «develop» и прочее).
Да, ручных разрешений конфликтов не избежать. Они появляются тогда, когда двое или больше программистов правят одни и те же строчки кода. Если они правят файл в разных местах, то конфликт разрешается автоматически как в Git, так и в SVN, насколько я понял.
Kdiff3 (или другая графическая объединялка) как инструмент слияния конфликтных файлов удобен тем, что показывает 4 панели:
1. Версия файла, с которой вы разошлись (общая для обеих веток)
2. Ваша версия
3. «Другая» версия (из другой ветки)
4. Результат слияния (в который можно вносить любые правки)
Насчет переименования/переноса файлов:
— В Mercurial такие операции нужно указывать явно (hg rename, если не ошибаюсь), тогда он будет отслеживать историю и конфликты правильно.
— В GIT файлы идентифицируются с помощью SHA-1, в результате, если хэши у файлов совпадают, GIT автоматически считает это одним файлом и ведет общую историю. Это называется «content-addressed storage».
Когда я выбирал VCS, я пытался «запутать» Mercurial копированиями, переименованиями и удалениями, но он со всем справился. В самых сложных случаях он спрашивал, удалить файл или оставить, если в одной ветке он редактировался, а в другой — удалился.
В hg тоже нужно комитить результаты слияния. Я пропустил этот шаг по ошибке, т.к. GUI объединяет эти два действия в одно. Если точнее, даже три действия — для редактирования конфликтов автоматически запускается Kdiff3 или любая другая объединялка.
У нас разработка происходит примерно так
1. Создаем папку для ветки mkdir mybrahch
cd mybrahch 2. Создаем ветку hg clone <project_path/URL>
3. Работаем… hg commit -m «Разработано что-то полезное»
4. Получаем последнюю версию из централизованного репозитория hg pull <project_path/URL>
5. Объединяем hg merge
6. Тестируем…
7. Если нашли ошибку, идем на п. 3
8. Обновляем централизованную ветку hg push <project_path/URL>
Преимущества:
1) в SVN имя ветки должно быть уникальным для всех, в распределенных системах имя ветки локально для разработчика и после объединения и синхронизации про ветку вообще можно забыть.
2) Git/Mercurial действительно умеет очень просто объединять ветки. Я в первый раз, когда объединил две ветки, а система не задала не единого вопроса, был даже немного напуган и прошелся по всем изменениям, убедившись, что система сделала все правильно.
Недостатоки:
1) в Git/Mercurial нельзя извлекать часть репозитория, а только весь репозиторий целиком. Для очень больших проектов это может стать проблемой
2) в Git/Mercurial плохо работать с бинарными файлами из-за того, что репозиторий в этом случае будет очень быстро расти в размере. Это может тоже быть плохо для веб-проектов.
SVN и Mercurial можно использовать совместно и я слышал, что так делают. Но подробностей не знаю.
Описанный рабочий процесс — интересный, но команды SVN для создания ветки и слияния выглядят просто жутко и отпугивают читателя. В GIT/Mercurial это просто 'git/hg merge', а все остальное система определяет автоматически.
Очень советую, попробуйте Mercurial (он проще), тем более, что он работает с централизованными репозиториями SVN.
Жалко, что нельзя посмотреть текст вашей переписки (без личных данных, конечно). Из него было бы легче увидеть суть кросс-культурного барьера и что-нибудь посоветовать.
http://webcast.berkeley.edu/series.html
Из прослушанных особо понравились:
CS162 Operating Systems Programming
C10 Physics for Future Presidents
Это субъективное, конечно, ощущение, но вознило почти у всех наших сотрудников, когда они по-одному переходили на hg.
Я совершенно не утверждаю, что SVN хуже объединяет. Но, например, в hg нет ключа '--reintegrate'. Он будет объединять ветки в любую сторону, а потом обратно и везде с минимальным участием человека в процессе.
По поводу неименованых бренчей я основывался тоже на документации, см. The flow of changes—big picture vs. little. Под неименованными ветками в этом разделе подразумевается короткоживущие ветки, которым специальные имена не дают и их изолируют в отдельном клоне репозитория.
Но, это терминологический спор, сути все равно не меняет. Вы тоже правы.
1. В Git с поддержкой Windows довольно плохо.
2. К Mercurial есть плагин позволяющий хранить временные штемпели отдельных файлов — специфика конкретного проекта.
3. Ревизии Git идентифицируются хэш-идентификаторам, что не удобно для кратковременного запоминания (пусть даже и части id). В Меркуриале идентификатор состоит из локального номера и глобального идентификатора (типа 143:ab46778a...), и в 99% случаях для работы с репозиторием достаточно запоминать номера.
Сравните,
git diff as5675ff:cfg7с261и
hg diff 100:145А так, оба инструмента очень хороши.
Kdiff3 (или другая графическая объединялка) как инструмент слияния конфликтных файлов удобен тем, что показывает 4 панели:
1. Версия файла, с которой вы разошлись (общая для обеих веток)
2. Ваша версия
3. «Другая» версия (из другой ветки)
4. Результат слияния (в который можно вносить любые правки)
Я б хотел привести конкретный пример или доказательство, но не могу — давно уже не пользуюсь SVN. Но по «ощущениям» все очевидно практически сразу, нужно пробовать.
На Хабре, кстати, есть много хороших статей по hg:
habrahabr.ru/blogs/development_tools/108443/
habrahabr.ru/blogs/development_tools/108658/
habrahabr.ru/blogs/development_tools/108904/
habrahabr.ru/blogs/development_tools/109074/
habrahabr.ru/blogs/development_tools/109203/ (слияние)
habrahabr.ru/blogs/development_tools/109428/
— В Mercurial такие операции нужно указывать явно (hg rename, если не ошибаюсь), тогда он будет отслеживать историю и конфликты правильно.
— В GIT файлы идентифицируются с помощью SHA-1, в результате, если хэши у файлов совпадают, GIT автоматически считает это одним файлом и ведет общую историю. Это называется «content-addressed storage».
Когда я выбирал VCS, я пытался «запутать» Mercurial копированиями, переименованиями и удалениями, но он со всем справился. В самых сложных случаях он спрашивал, удалить файл или оставить, если в одной ветке он редактировался, а в другой — удалился.
1. Создаем папку для ветки
mkdir mybrahch
cd mybrahch
2. Создаем ветку
hg clone <project_path/URL>
3. Работаем…
hg commit -m «Разработано что-то полезное»
4. Получаем последнюю версию из централизованного репозитория
hg pull <project_path/URL>
5. Объединяем
hg merge
6. Тестируем…
7. Если нашли ошибку, идем на п. 3
8. Обновляем централизованную ветку
hg push <project_path/URL>
Преимущества:
1) в SVN имя ветки должно быть уникальным для всех, в распределенных системах имя ветки локально для разработчика и после объединения и синхронизации про ветку вообще можно забыть.
2) Git/Mercurial действительно умеет очень просто объединять ветки. Я в первый раз, когда объединил две ветки, а система не задала не единого вопроса, был даже немного напуган и прошелся по всем изменениям, убедившись, что система сделала все правильно.
Недостатоки:
1) в Git/Mercurial нельзя извлекать часть репозитория, а только весь репозиторий целиком. Для очень больших проектов это может стать проблемой
2) в Git/Mercurial плохо работать с бинарными файлами из-за того, что репозиторий в этом случае будет очень быстро расти в размере. Это может тоже быть плохо для веб-проектов.
SVN и Mercurial можно использовать совместно и я слышал, что так делают. Но подробностей не знаю.
Очень советую, попробуйте Mercurial (он проще), тем более, что он работает с централизованными репозиториями SVN.