×Закрыть

Mercurial: введение в распределённые системы контроля версий

Что, почему, для чего?

Примерно года полтора назад я заинтересовался распределёнными системами контроля версий (хотя и слышал о них раньше, обычно о git’е, который в то время под Windows не работал, что мне было критично), когда наткнулся на сайт Bazaar’а. Подогревали мой интерес обещанные разработчиками блага, в том числе и возможность коммитить без подключения к интернету, но порядочно напрягало то, что передача данных на сервер происходила действительно долго (и даже по локальной сети передача одного коммита занимала несколько секунд).

После нескольких месяцев использования Bazaar’а в своих проектах на каком-то из сайтов я заметил анонс (и немножечко дифирамбов) выхода Mercurial’а, тоже распределённой системы версий и тоже написанной на Python (тогда это была версия 0.9.4). Дифирамбы эти меня привлекли, и я решил попробовать, и не смог оторваться, настолько система работала быстрее. Её скорость первое время меня поражала, основной набор команд не отличался от привычного мне Subversion’овского, а к графическим интерфейсам я не особо пристрастен, и потому меркуриал быстро и прочно вошёл в мою жизнь.:)

Где-то через полгода после этого мой коллега по проекту MyDeco проникся знаменитым выступлением Линуса Торвальдса, и с новой силой мы принялись убеждать руководство, что нам просто необходимо перейти на распределённую систему контроля версий. После сравнения претендентов (не последнюю роль в выборе системы, конечно, сыграло моё близкое знакомство с одной из них) остановились на меркуриале.

Нельзя сказать, чтобы переход был слишком уж гладкий, но за неделю понять режим работы и обучиться работать смогли все (не исключая дизайнеров;)), и можно сказать, что именно в этот момент я действительно понял, насколько использование такого инструмента повышает качество работы. Об этом можно судить как по отзывам тестировщиков, так и по уменьшившемуся количеству появляющихся за неделю тикетов о проблемах — банально низкокачественные ревизии не пропускались в главный репозиторий.

И мне просто хочется поделиться позитивным опытом использования более продвинутого инструмента, чем применяющийся обычно в разработке сегодня. Но начнётся всё, как обычно, издалека — с самого начала.

Немного истории

Ноги у обеих наиболее популярных сегодня DVCS (Git и mercurial) растут из одного и того же места.;) Как и положено, таких ног две.

Примерно в то же время, когда стартовал проект по созданию «правильного CVS» — Subversion, было положено начало и другому — Monotone, который был действительно инновационным по сравнению с предшественниками: например, для идентификации ревизий использовался не порядковый номер, а криптографический SHA1-хэш, что позволяет безошибочно определять уникальность данной ревизии.

Чуть позже, в феврале 2002 года, разработка ядра Linux была переведена с использования диффов и патчей (без войн, естественно, не обошлось) на проприетарную распределённую систему контроля версий BitKeeper, написанную Ларри МакВоем (Larry McVoy). Система, конечно, не безгрешная (и уж явно неудобная для всех, кроме Линуса, тем, что не позволяла посмотреть историю изменений), но работавшая, как говорил Линус, заметно лучше CVS (и его потомков). Хорошо известно высказывание Линуса на тему того, что Subversion — это самый бесцельный проект в истории, учитывая слоган проекта «CVS done right», в то время как CVS — изначально порочная концепция.

Всё продолжалось достаточно спокойно до тех пор, пока Эндрю Триджелл (Andrew Tridgell — один из главных разработчиков Samba) не «нарушил» лицензию (которую он, впрочем, не подписывал) BitKeeper’а, взломав reverse-engeenering’ом протокол — довольно анекдотичный случай, все действия по взламыванию протокола заключались в соединении telnet’ом с сервером и отправлением слова «help», что вывело справку по использованию сервера.;) Как бы то ни было, Ларри сделал невозможным бесплатное использование BitKeeper’а, и Линукс остался без системы контроля версий.

В ходе активных поисков наиболее подходящим проектом казался Monotone, который имел больше возможностей и потенциала, чем любая другая open source система контроля версий, и всего лишь одну, но очень большую проблему — крайне низкую скорость работы. Так как особенности дизайна Monotone не позволяли его ускорить на несколько порядков (в то время алгоритм добавления файлов имел сложность O (N**3), где N — количество добавляемых файлов), Линус начал разрабатывать Git. Практически одновременно с ним (насколько я знаю, несколько дней разницы в старте — 3 и 6 апреля 2005 года), но до анонса разработки Git’а, другой kernel-hacker, Мэтт Макал (Matt Mackall), начал разрабатывать аналогичную систему (с теми же целями), но на языке Python — Mercurial (только критичные к скорости места, например diff, написаны на C).

Естественно, что с развитием системы её начинало использовать всё больше и больше проектов, и среди реальных мастодонтов, использующих Mercurial в текущий момент в качестве основной системы контроля версий, можно отметить Mozilla, NetBeans, Java (в вики меркуриала можно посмотреть более полный список таких проектов).

Зачем вся эта распределённость

Скорее всего, для большинства людей, особенно успешно использующих централизованные системы контроля версий, остаётся непонятным — зачем было завязывать весь этот сыр-бор с распределённостью и почему нельзя было взять уже стабильную, развивающуюся много лет систему с отличной инфраструктурой в видехостингов, GUI-утилит и т. п., например, Subversion. Тем более, что в распределённых системах постоянно необходимо объединять различные ветки, что, как всем известно;), довольно трудоёмкая задача.

Однако, если присмотреться поближе, можно увидеть, что у DVCS на текущий момент есть только один недостаток по сравнению CVCS — меньшая распространённость, но очень большое количество преимуществ.

Начну со слияния (merge). Слияние в DVCS — это совсем не то же самое, что объединение веток в SVN. Это аналог svn update, при котором исключена потеря данных — ведь они уже сохранены в ревизиях. Операция простая и не требующая особых усилий, а с хорошей утилитой для мержа вообще превращающаяся в тривиальную.

Дальше, естественно, вспоминается повсеместно упоминаемая возможность работы в офлайне — её тоже не стоит недооценивать. Помимо полезности в тот момент, когда нет соединения с сервером, появляется возможность обменяться ревизиями с коллегой, минуя сервер (если они ещё не готовы для публикации), ну и просто что-то экспериментальное покрутить втайне от других.;)

Даёт это ещё порядочный fault tolerance — если что-то случилось с репозиторием, существует куча его бекапов. Собственно, каждый клон — и есть бэкап.:)

Лично для меня одним из самых больших плюсов являлась скорость работы — меркуриал выполняет базовые операции (commit/diff/log/annotate) в несколько раз быстрее SVN, работающего локально. А уж про svn, работащий по сети, можно и не упоминать — с плохим каналом коммиты становятся нудными до смерти, а svn log я вообще предпочитал трогать в крайних случаях. Здесь log занимает до пары десятых секунды в случае, когда кеш файловой системы забит чем-то другим, при этом от размера репозитория скорость не зависит — она линейна.

Очень полезна та особенность, что доступ к репозиторию на запись для всех разработчиков не является необходимостью, причём полезна она не только для opensource проектов (где это очевидно, когда есть небольшое количество постоянных разработчиков и людей, время от времени контрибутящих какой-то код), но и для коммерческих. К примеру, право на запись в основной репозиторий имеют только тимлиды, которые делают беглый ревью кода своей команды перед записью, что немало помогает достижению цели неразломанности репозитория.:)

В общем и целом всё это даёт возможность сказать, что использование DVCS значительно упрощает жизнь программиста, а знакомство с определёнными особенностями таких систем (которые будут рассмотрены дальше) увеличивает количество возможных маневров в сложных ситуациях.

План последующих статей

Я планирую опубликовать цикл статей, посвященных Mercurial и DVCS, примерно такого содержания:

  • Основы Mercurial
    • Базовые принципы
    • Workflow (технологический процесс?)
    • Merge
    • Обмен данными по сети
    • Особенности работы
    • Недостатки
  • Дополнительные возможности
    • bisect
    • mq
    • graphlog
    • record
    • transplant
    • hgk
    • Web
    • TortoiseHG
  • Альтернативы Mercurial: Git, Bazaar

Дополнения/замечания по намеченному плану принимаются.

См. также продолжение: Mercurial: основы.

  • Популярное

34 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Перевел две страницы. Уфф.:)

Александр, а не хотите поучаствовать в переводе hgbook? http://translated.by/you/distr.../

Понравилось что Mercurial имеет встроенный GUI браузер для просмотра репозитария который можно запустить из командной строки: hg view

Сегодня я перешел с SVN на Mercurial. Я использовал для конвертации hgimportsvn. Я поставил себе плагин Mercurial’а на Intellij Idea, работает нормально. Действительно, Mercurial работает шустрее.

Очень интересно и позновательно, я коечто почерпнул для себя

А, что bzr действительно удобная штука q:

Хех, тролли на DOU, часть 1. FUD is gay, вы в курсе?

настойчиво рекомендую не связыватся с этой бякой. bzr и git куда юзабельней.дешевле запгрейтить комп под bzr чем тратить нервы на mercuril\wbr Vitaly Chernookiy

у DVCS на текущий момент есть только один недостаток по сравнению CVCS — меньшая распространённость

Я не сильно разобрался пока с децентрализованной системой, но у меня возник вопрос: Раз у каждого участника хранится полная копия всего репозитария, то как тогда осуществляется разграничение доступа? В SVN/CVS/SourceSafe/StarTeam я могу назначать различные права доступа на каталоги. Если в разработке проекта участвуют фрилансеры (или часть кода отдается на аутсорсинг), то разграничение прав доступа просто необходимо.

Поправка к первому сценарию: «Будет ли отдан приоритет более раннему фиксу из A даже если мы только что уже вручную зарезолвили его в пользу b в нашей ветке? »

Ок, еще пару сценариев. После шага 3, мы снова мержим самую последную версию A с уже зарезолвеным конфликтом в B. Будут ли конфликты? Будет ли отдан приоритет более раннему фиксу из B даже если мы только что уже вручную зарезолвили его в пользу b? Другой сценарий.В ветке A тоже пишут ту самую фичу. После этого её мержат в B, и при конфликте на новом коде решают его в пользу реализации из B, позднее то же самое делают в A, но как обычно резолвят в свою пользу (обращаю внимание на другой хронологический порядок). Сливая потом эти версии поломаются ли обе ветки?

> 5. Ветки сливают снова. Если разрешение конфликта в ветке A хронологически более ранее, то что происходит с изменениями внесенными после мержа A в B? Они остаются. Всё-таки системе контроля версий пока не понятно, что эти изменения как-то связаны. Хотя было бы логично, чтоб опять случался конфликт. Я, наверное, пойду с разработчиками завтра пообсуждаю эту штуку...

Моему не закаленному DVCS’ами мозгу не сразу ясно как оно «обычно» =) Вот такой сценарий я себе нарисовал: 1. есть баг, к нему сделали два фикса — a и b, допустим для внешнего мира они идентичны, но внутренняя реализация разная. 2. Потом в одной ветке при конфликте выбрали фикс, а образовав ветку A, а в другой выбрали b образовав B. 3. Хозяин ветки A мержил ветку B и выбрал в этом конфликте фикс a, хозяин B в той же ситуации выбрал b.4. Затем в ветке B занялись развитием функционала и добавили какую-то фичу которая, так вышло, зависит от деталей реализации фикса b.5. Ветки сливают снова. Если разрешение конфликта в ветке A хронологически более ранее, то что происходит с изменениями внесенными после мержа A в B?

> А если при втором слиянии (образовывающем D) больше изменений чем общий фикс, что происходит с ними? Не понял. Ты имеешь в виду, что будет, если будут присутствовать не только вот эти конфликтующие мержи-фиксы, но и какие-то другие изменения? Для них ничего не изменится — всё будет, как обычно.

А если при втором слиянии (образовывающем D) больше изменений чем общий фикс, что происходит с ними?

> Дрова в костер.Только что попробовал меркуриал — он оставляет тот мерж, который произошёл раньше. Пробовал пуллить и с одной стороны, и с другой — остаётся тот, что по времени произошёл раньше.

Могу написать про git, если есть потребность (?)

Потребность есть. Хочется услышать поподробнее про процесс merge и использование bisect, и в общем как грамотно применять git.

2 Alexey Smirnov: Могу написать про git, если есть потребность (?) Можете также почитать немного про git изнутри: http://random-state.net/log/34... (и вперед по ссылке next)

Спасибо за статью! Я уже перешел на Hg благодаря заметкам в piranha.org.ua и теперь очень доволен =)

Очень интересно, буду обязательно следить.А Вы случайно не собираетесь, после завершения этой серии статей, написать еще про GIT?

Историю можно было изложить и получше. Хотя бы работу Эрика Реймонда, проглядели бы по диагонали.

Хм. В принципе да, но он не слишком много отношения имеет к тому, что DVCS начали набирать популярность. Вон Брэм Коэн — тоже кучу работы сделал, мега-гипер-алгоритм мержа, но в итоге что это дало для популяризации DVCS? Почти ничего.

> Используйте git:) Тролль!: D> із альтернатив ще є Darcs.Но со скоростью у него, даже у 2-го...: (> По плану статей: про недостатки очень интересно — буду ждать с нетерпением. Интересно, ЧТО именно вы перечислите.Хе-хе. На деле я немного зарылся в формат и понял, что некоторых проблем не существует. А сейчас самая большая на мой взгляд — это реализация ренейма... Впрочем, в базаре из-за трекинга директорий всё точно так же весело. Если хочется увидеть что-то конкретное — вполне возможно, что я пропущу большинство того, что является проблемой для тебя — велкам в мыло.> По расширениям: предлагаю добавить обзор win32text и forest.Ну первое — в принципе можно, я хоть его и не юзал, но оно простое. А второе... Ну хз, можно с ним поиграться и написать, но реально опыта применения где-то серьёзно у меня нету, а я думаю, что там хватает подводных камней.

Историю можно было изложить и получше. Хотя бы работу Эрика Реймонда, проглядели бы по диагонали.По плану статей: про недостатки очень интересно — буду ждать с нетерпением. Интересно, ЧТО именно вы перечислите.По расширениям: предлагаю добавить обзор win32text и forest.

із альтернатив ще є Darcs.

Интересно, на Лоре обгадят или нет?

Спасибо за инфомацию о DVCS, узнал много нового, раньше и не подозревал насколько это хорошая вещь...

для mq точно стоит отдельно написать. advanced topic типа. я как раз думал использовать mq чтобы отслеживать наши патчи к wordpress и куче другого кода, который используется у нас на сайте.

хоть что-то интересное за последий месяц =)

> Спасибо, отличная статья.Дальше будет лучше, я думаю. =) Правда, я ещё возможно mq выделю в отдельную часть — зависит от того, насколько оно длинным выходить будет. Базовые принципы можно описать довольно кратко и быстро, но в действительности можно писать и писать.:) Не зря ж ему две главы в hgbook’е посвятили...> Рабочий процесс.О, реально. Пасиб.

Workflow (технологический процесс?)

Делопроизводство Рабочий процесс.

Спасибо, отличная статья.

С удовольствием почитаю. Сам хочу переползти с SVN на Mercurial.

Подписаться на комментарии