*** ВНИМАНИЕ: Блог переехал на другой адрес - demin.ws ***

четверг, 21 мая 2009 г.

Какую распределенную систему контроля версий выбрать: Git, Bazaar или Mercurial?

Последние две недели занимаюсь вялотекущим сравнением трех распределенных систем контроля версий: Git, Bazaar и Mercurial.

Перечитал множество отзывов и сравнений, но ясно, надо попробовать все самому для своих задач.

Исторически Git для меня самая родная система, так как пользуюсь ей дольше всего. Поэтому пост будет во многом Git'оцентричный.

С Bazaar познакомился благодаря отличному блогу "Базарный день".

Mercurial пришлось попробовать, так как это православно (причем весьма заслуженно).

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

О колокольне, с которой я смотрю на предмет. Я ищу систему не для дома (собственные проекты у меня сидят на разных системах, и все нормально), а для поддержки системы на нескольких видах UNIX плюс еще и Windows. Примерное количество файлов в ветке проекта около шести тысяч. Объем ~250 мегов (увы, есть некоторое количество двоичных файлов). Объем репозитория особо не волнует, если речь идет о разумных цифрах.

Git

Это скальпель. Время обучения и погружения в систему несколько больше, чем у конкурентов, но более менее приноровившись понимаешь, какой инструмент у тебя в руках. Начинающий пользователь с Git'ом в руках выглядит как ребенок, режущий колбаску хирургическим скальпелем.

Теперь по делу.

Что мне очень нравится в Git — это наличие staging системы (промежуточное звено между рабочими файлами и репозиторием). Очень удобно, когда можно подготовить для комита не весь файл, а только его часть.

Очень удобная система stashing для хранения временных наработок и переключения между ними без создания ветки, когда надо отвлечься на минуту для эксперимента.

Очень подкупает невообразимо мощная команда rebase, которой можно сделать с историей проекта все (в том числе и испортить). То есть Git не возводит в религию неприкосновенность истории. Механизм для ее модификации дается, но вот ответственность за результат перекладывается на пользователя. Никто не запретит тебе простым ключиком "--amend" подправить синтаксическую ошибку в тексте последнего комита (да и любого другого комита) или удалить любой комит из истории, но вот надо тебе или нет — вопрос персонального подхода к работе. Из личного опыта как занимающего выпуском релизов скажу, что порой очень нужно иметь возможность менять историю, увы. В Perforce мне из-за этого приходится делать много ручной работы.

Под занавес — есть приятный бонус в виде качественного публичного хостинга github.com.

Из минусов, трогающих меня — это просто омерзительный порт под Windows. Я пользуюсь версией, построенной на MinGW. Пока непобежденным глюком для меня является тот факт, что по какой-то причине некоторые базовые утилиты UNIX, входящие в состав дистрибутива Git под Windows, при старте пытаются, видимо, определить наличие всех логических дисков (C:, D: и т.д.) в системе. Хорошо, когда нет сетевых дисков, а вот когда они есть, то такой опрос занимает раздражающие 2-3 секунды при каждом запуске (причина была выявлена путем анализа сетевого трафика, так как сначала я думал, что у меня вирус). На домашнем компьютере все отлично — там нет сетевых дисков.

Но несмотря на все препоны, с помощью git-p4 я наладил для некоторых наших разработчиков, работающих часто в офлайне, неплохой механизм интеграции с централизованным Perforce. Человек синхронизируется, будучи онлайн, и обновляет локальный репозиторий Git. Потом спокойно работает в офлайне через Git, а затем опять в онлайне засылает все сделанное из Git в Perforce.

Bazaar

Классная система. Работает с полоборота из коробки, но только там, где есть Питон, поэтому на некоторых наших вынужденных UNIXах меня ждал облом.

Пока я не нашел особых смысловых изъянов, мешающих мне работать.

Очень мне нравится подход, когда каждая ветка как таковая живет в отдельном каталоге, то есть имеет свой набор рабочих файлов (хотя может и не иметь).

Как-то с ходу не нашел бесплатного хостинга для Bazaar.

Mercurial

Снова Питон, поэтому автоматически все шоколадно на системах, где он есть, но грустно, где его нет.

Из хороших бонусов есть факт, что Google сделал поддержку хостинга для этой системы. Как написано в их отчете о том, почему они выбрали именно Mercurial, а не Git, как я понял, говорится, что основные причины в более простой интеграции Mercurial в систему http-сервисов (Git тоже умеет через http, но медленнее), и логическая близость синтаксиса команд Mercurial к Subversion (тут, конечно, Git ой как далеко).
В целом, для себя я решил пока так: если для дома для семьи или там где Windows да Linux, то это без сомнения Bazaar или Mercurial (можно монетку подкинуть), а вот все-таки для применения на множестве разнородных систем и там где надо уметь управлять историей, то пока Git.

8 комментариев:

  1. Для решения проблемы с "Юникс" утилитами рекомендую попробовать работать из cygwinа.
    там тоже происходит подвис, но только при старте шелла.

    ОтветитьУдалить
  2. Да, Cygwin помогает. Тут можно просто Git из исходников собрать. Но все это становится сложно, когда надо людям ставить все это. Никто не захочет ради Git'а ставить себе Cygwin. Неудобно, одним словом.

    ОтветитьУдалить
  3. Бесплатный хостинг для Bazaar -- это Launchpad.net.

    ОтветитьУдалить
  4. Git тормознее чем Mercurial.
    Мне больше Mercurial нравится.

    ОтветитьУдалить
  5. bialix: Приятно. А вообще публичные depot'ы - это мега подход. Тут тебе и бекап и работа с коллегами. Выкладывание исходников на публику сразу как-то дисциплинирует ;-)

    davaeron: Тормознее по сути? а не из-за кривой версии под винды? Конечно у всех характер хранимых данных разный, и тут сложно сделать какое-то объективное сравнение, удовлетворяющее всех.

    Меня другое последнее время интересует: идея централизованных систем как таковых с головой покрывается распределенной моделью. Ведь никто не мешает иметь центральной depot, куда все будут push'ить. Просто при этом еще каждая рабочая станция является полноценным звеном, ведущим историю, и могущим обмениваться с другими станциями.

    К сожалению, например, у нас Perforce на боевом дежурстве уже более 7 лет, и просто так заменить все на распределенную систему, увы, никто не хочет, причем функционально все может также, или лучше.

    ОтветитьУдалить
  6. Александр: http://code.google.com/p/support/wiki/DVCSAnalysis
    1 As a benchmark, Git and Mercurial repositories were seeded with approximately 1500 files totaling 35 M of data. The servers were running in Chicago and the clients in Mountain View (51 ms ping time). The operation of cloning the remote repository (similar to a initial checkout in traditional version control systems) averaged 8.1 seconds for Mercurial and 178 seconds for Git (22 times slower). A single file in the repository was then changed 50 times and the clients pulled the updates. In this case, Mercurial took 1.5 seconds and Git required 18 seconds (12 times slower). When the Git protocol was used instead of HTTP, Git's performance was similar to Mercurial (8.7 seconds for cloning, 2.8 seconds for the pull).

    btw, мой Вам совет, не меняйте Perforce на DVCS if you don't know what you're doing.

    ОтветитьУдалить