Thu 22 Jan 2009
Mercurial, полет нормальный
Posted by Alex Lebedev under mercurial, инструменты
[4] Comments
Не так давно я обосновывал, что git лучше, чем Mercurial. К сожалению, невозможность увязать LDAP-авторизацию иначе, чем через WebDAV, поставила крест на использовании git. WebDAV оказался непригоден для транзакционных операций с большим числом файлов, репозиторий постоянно приходил в некорректное состояние. Примерно через неделю разборок с WebDAV нам надоело жрать этот кактус и было решено использовать Mercurial.
Прошел почти месяц и уже можно твердо сказать, что решение было удачным.
Приятности
По сравнению с SVN лучше практически все: отличная скорость, удобная работа с бранчами.
Никаких проблем интеграции с Trac, все сделано на аналогичном SVN’у уровне
Для одновременной работы с SVN и Mercurial существует отличная утилита hgsvn. Мы ее использовали при импорте истории из SVN, все прошло гладко. В моем домашнем репозитории, правда, возникли мелкие проблемы с распознаванием кодировок, до решения которых пока не дошли руки.
Для Windows существует достаточно приятный TortoiseHg. Лично мне удобнее работать с клиентом командной строки, зато Tortoise обеспечивает удобный интерфейс для просмотра логов. На *nix визуальный показ лога входит в ядро Mercurial и вызывается командой
hg view.Mercurial действительно оказался значительно проще в изучении, чем git.
Потенциальные проблемы
Основная проблемная область при переходе c SVN на Mercurial — работа с бранчами и все что с ней связано. Это очень мощная и полезная функциональность, но при неаккуратном использовании может получиться вот такая лапша:

На картинке вы видите последствия одного коммита в неправильный бранч и последовавший процесс исправления этих последствий.
Настоятельно рекомендую перед миграцией на Mercurial хотя бы одному члену команды внимательно прочитать документацию. Проблемы в первое время обязательно будут возникать, и кто-то должен уметь их решать. Если вы раньше не работали с распределенными системами контроля версий, то интуиция в решении этих проблем не поможет, нужно будет четкое понимание того, что происходит внутри.
Мелочи, на которые стоит обратить внимание:
hg pushтребует флага-fпри создании новой “головы”, даже если вы работаете в рамках давно существующего бранча.После мержа все изменения в рабочей копии должны быть закоммичены в рамках одной транзакции. В ряде ситуаций это бывает очень неудобным. Всегда коммитьте все локальные изменения перед мержем!
Материалы
TortoiseHg — интеграция Mercurial в “Проводник” Windows
hgsvn — утилита для одновременной работы с Mercurial и SVN
Converting from Subversion to Mercurial — отличное руководство по переносу репозитория из SVN в Mercurial

January 23rd, 2009 at 07:40
Я hg использую для всяких коммунити-проектов, а на работе svn. Так вот в svn сильно не хватает hg record (добавляется включением hgext.record), позволяющее выбирать, какие изменения в рабочей копии коммитить.
January 23rd, 2009 at 12:11
Разве не для этого ветки нужны? svn же позволяет указывать какие файлы комитить. Или речь об изменениях в пределах файла?
И как можно быть уверенным, что ничего не поломается после такого комита (например, тесты)?
January 23rd, 2009 at 01:47
Дмитрий Гусев:
hg recordпозволяет выбирать в том числе конкретные блоки изменений внутри одного файла.Вопрос с тестами правомочен. Нормальным решением будет сделать локальный клон и запустить тесты в нем, хотя это и не особо удобно. Еще можно убрать остальные изменения c помощью
hg shelve(аналогgit stash) и прогнать тесты на текущей рабочей копии. Будем надеяться,shelveскоро включат в стандартную поставку Mercurial, пользоваться плагином не так удобно.January 24th, 2009 at 05:12
hgsvn не очень клёвый, hgsubversion лучше – он может коммиты обратно возвращать. Неожиданно ещё и в твиттере приехало.
А на тему shelve – есть mq, входящий в поставку. Немного больше возни при простых ситуациях, но зато очень удобен и гибок, когда есть несколько разных патчей.