Курсы Университета Беркли: 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.
Жалко, что нельзя посмотреть текст вашей переписки (без личных данных, конечно). Из него было бы легче увидеть суть кросс-культурного барьера и что-нибудь посоветовать.
Спасибо за ссылки! По-видимому научное сообщество еще не достигло консенсуса в этом вопросе:
Cell phone also use microwaves to carry their signals. Do you dare put a cell phone up to your ear? There are many urban legends about that. Low levels of microwaves cause only low levels of heating, and your eyes can handle that with no trouble. Microwaves do not have the ability to damage DNA in the same way as x-rays and gamma rays. Most of the fear that microwaves can cause cancer is simply a reaction to the fact that microwaves are sometimes called microwave radiation, and the use of the term radiation frightens some people.
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.
Цитата из «Physics for Future Presidents» prof. R. Muller.