Просмотр исходного текста страницы Distributed Version Control Systems: A Not-So-Quick Guide Through

Перевод статьи «[http://www.infoq.com/articles/dvcs-guide Distributed Version Control Systems: A Not-So-Quick Guide Through]» от ''Sebastien Auvray'' с портала InfoQ.

[[Image:3-atlets-on-start.jpg|right|200px]]

{{note}} Sébastien Auvray — senior software designer и энтузиаст технологий. Его заставляли использовать [[CVS]] и [[SVN]], теперь он страдает на работе от ежедневного использования Perforce. Sébastien также один из редакторов InfoQ по теме Ruby.


{{caution}} К моменту перевода прошел уже год, и многие положения статьи изменились — самые очевидные исправлены переводчиком ([[Участник:StasFomin|Стас Фомин]]) (в частности, исправлены битые ссылки), часть снабжены сносками, указывающими на произошедшие изменения.

После [[Линус Торвальдс о GIT на Google Talks|выступления Линуса Торвальдса в Google]] в мае 2007, просвященного GIT, постоянно растет интерес и число пользователей распределенных систем контроля версий (''Distributed Version Control Systems'', DVCS).

Тут мы сначала сделаем краткое введение в понятия распределенного управления версиями, посмотрим, когда это стоит использовать, и почему, этом может быть лучше, чем то, что вы используете сейчас, и затем мы взглянем на трех ключевых игроков в этой области: <tt>git</tt>, <tt>Mercurial</tt> и <tt>Bazaar</tt>.

== Так что же это? ==

Системы управления версиями (СУВ, SCM, ''Source Control Management'') следят за всеми версиями каждой информационной единицы.
Обычно они используются в разработке ПО для ведения исходных кодов проекта.
Самой древней из широко известных СУВ была [[CVS]], разработка началась в 1986 году.

С тех пор выросло множество СУВ, различным образом улучшающих CVS:
* [http://subversion.tigris.org/ Subversion] (2000);
* [http://www.perforce.com/ Perforce] (1995);
* [http://www.march-hare.com/cvspro/ CVSNT] (1998)…

[[Image:braches-in-vcs.png|left]]

В декабре 1999, для ведения основного ствола исходников Ядра Линукса Линус выбрал [http://www.bitkeeper.com/ BitKeeper], характеризовав его как «Лучший инструмент для этой работы».

До этого, Линус вообще вручную интегрировал изменения из отдельных патчей.

Все предшественники ''BitKeeper'' работали в централизованной модели «Клиент—(Центральный)Сервер», и ''BitKeeper'' был первой VCS разрешивший полную распределенность, когда каждый имеет собственный репозиторий. Но из-за лицензионных конфликтов, ''BitKeeper'' был отринут в пользу [http://git.or.cz/ git] (апрель 2005).

Теперь есть и другие системы, использующие ту же модель:

* [http://www.selenic.com/mercurial/wiki/ Mercurial] (апрель 2005);
* [http://bazaar-vcs.org/ Bazaar] (март 2005);
* [http://darcs.net/ darcs] (ноябрь 2004);
* [http://monotone.ca/ Monotone] (апрель 2003).

== Зачем все это? ==

Или даже более конкретно: «А чем не устраивают CVCS (Централизованные СУВ)? Subversion-то чем не угодил?»

Вот в чем обвиняют <tt>Subversion</tt>:
* Главное: ветвится стало легко, но слияние-то по-прежнему мучительно (а ведь зачем «ветвление без слияний?»). Наверняка во всех проектах вам придется развлекаться с ветками разработки и тестирования. А у <tt>Subversion</tt> нет «безопасного повторного» слияния, пользователей заставляют вручную отслеживать интервалы ревизий, которые уже были интегрированы в другие ветки, и все это разумеется подвержено ошибкам.
* Никак не послать изменения другому пользователю минуя центральный сервер.
* ''Subversion'' не может интегрировать измененения при переименовании файлов или каталогов<ref>Появилось в версии 1.6 (примечание переводчика).</ref>.
* Нужно специально придерживаться «trunk/tags/branches»-соглашения о ветках (См. [http://www.jroller.com/bokmann/entry/questioning_subversion_practices misleading]).
* Нет оффлайн-коммитов.
* Подкаталоги <code>.svn</code> замусоривают рабочую копию.
* Обработка свойства <code>svn:external</code> может быть опасна.
* Производительность: [http://wiki.netbeans.org/HgMigrationReasons Performance]

Современные DVCS-системы все это исправили, как собственными фишками реализации, так и самой идеологией распределенности.

Но, как мы увидим дальше, <tt>Subversion</tt> еще не сдается!

== Как? ==

=== Децентрализация ===

Распределенные системы управления версиями выигрывают за счет «peer-to-peer»-подхода.
Участники могут взаимодействовать друг с другом и поддерживать их локальные ветки без необходимости в центральном сервере и даже репозитории. То есть синхронизация идет между равными участниками, самостоятельно решившими, какими изменениями обменяться.

[[Image:CVCSvsDVCS.png|center]]

Это приводит к сущетвенным отличиями и преимуществам над централизованными системами:
;По умолчанию нет канонической, рекомендованной копии: только рабочие копии.
;Оффлайн операции: Большинство операций, таких как коммиты, просмотр истории или различий, откат изменений становятся быстрыми, ибо не нужно взаимодействие с центральным сервером.

Даже если есть какой-нибудь центральный сервер (например, для релизов, бэкапов или стандартных версий), если правильно задействовать ''Распределенность'', его не будут так же часто дергать, как в случае CVCS.

* Каждая рабочая копия на самом деле представляет собой полный бэкап всех исходников '''с историей правок''', в общем, естественным образом образовалась надежность от потери данных.
* Экспериментальные ветки — ветки очень просто и быстро создаются и уничтожаются.
* Участникам легко взаимодействовать друг с другом.

Для введения в непосредственно практики DVCS-разработки, можете взглянуть на статьи
[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated)] или возможно [http://bazaar-vcs.org/Workflows Collaboration workflows].

С другой стороны, стоит предупредить вас о некоторых проблемах выбора DVCS, особенно о проблеме сложности использования: этот децентрализованный подход весьма отличается от старого доброго Централизованного Мира, и может потребоваться время, чтобы ваши разработчики смогли им воспользоваться. Отслеживание наборов изменений (''changeset'') вместо ведения истории файлов тоже может запутать, несмотря на свою мощность, благодаря которой он сможет отслеживать такие вещи, как перемещение функции между файлами.

== Кто? ==
А теперь ''контрольверсийсрач''!
«Что такое хорошо, и что такое плохо».

Все эти плюсы и минусы собраны в основном из (вычитанной и проверенной, ибо многие аргументы устаревали) компиляции блогов и личного опыта.

{{caution}} Учтите, что это весьма краткий лист свойств (например, у <tt>git</tt> более 150 команд), и что важность их разная.

Для простоты, приведем сначала общие свойства всех трех систем:
* Модель конкурентного взаимодействия: «Слияние»
* Лицензия: GPL
* Бесплатны
* Основные возможности:
** Атомарные коммиты
** Слияния переименований файлов
** Поддержка симлинков
** Пре- и пост- триггеры (''hooks'') на события
** Отслеживание слияний
** Теги

Теперь приведем сводную таблицу различающихся свойств:

{|style="border:1px dashed orange" border=1
|
| git
| Mercurial
| Bzr
|-
|
| [[Image:git-logo.png]] http://git.or.cz/
| [[Image:mercurial-logo.png]] http://www.selenic.com/mercurial/
| [[Image:bzr-logo.png]] http://bazaar-vcs.org/
|-
| ГлавАвтор
| ''Junio C Hamano''
| ''Matt Mackall''
| ''Canonical Ltd.'' (идет переход в GNU project)
|-
| Платформы
| POSIX, Windows, Mac OS X
| Unix-like, Windows, Mac OS X
| Unix-like, Windows, Mac OS X
|-
| Версия
| {{Ok}} > 1.0 (1.6.5.1)
| {{Ok}} > 1.0 (1.3.1)
| {{Ok}} > 1.0 (2.0.0)
|-
| Запуск проекта
| апрель 2005
| апрель 2005
| март 2005
|-
| Реализация
|
|
|
|-
| SLOC (без тестов)
| [[Image:git-sloc.png]]
| [[Image:hg-sloc.png]]
| [[Image:bzr-sloc.png]]
|-
| SLOC Count
| 130550
| 38172
| 79864
|-
| Покрытие тестами (% исходников относящихся к тестам)
| {{Ok}} ~20 %
| {{Ok}} ~25 %
| {{Ok}} ~50 %
|-
| Модель истории
| ''Snapshot''
| ''Changeset''
| ''Snapshot''
|-
| Рост репозитория
| ''O(patch)''
| ''O(patch)''
| ''O(patch)''
|-
| Сетевые протоколы
| HTTP, FTP, email bundles, custom, ssh, rsync
| HTTP, ssh, email
| HTTP, SFTP, FTP, ssh, custom, email bundles
|-
| Подпись ревизий
| {{Ok}}
| {{Ok}}
| {{Caution}} Частично/Ручная проверка<ref>Подпись происходит автоматически, но проверка полуручная http://bazaar-vcs.org/BzrGpgSigning</ref>
|-
| Слияние изменений
| {{Ok}}
| {{Ok}}
| {{Ok}}
|-
| EOL-соглашения
| {{Ok}}
| {{Ok}}
| <s>{{No}} Запланировано в 1.6</s>{{Ok}}<ref>Есть начиная с версии 1.14 http://doc.bazaar-vcs.org/bzr.1.14/en/release-notes/NEWS.html#bzr-1-14</ref>
|-
| Интернационализация
| {{No}}
| {{Ok}}
| {{Ok}}
|-
| Частичный checkout
| {{No}} Используйте вместо этого подмодули
| {{No}} Запланировано
| {{No}} [http://bazaar-vcs.org/FilteredViews Запланировано]
|-
| Модель / Архитектура
|
|
|
|-
| Файлы
| Один подкаталог <code>.git</code> вверху
| Один подкаталог <code>.hg</code> вверху
| Один подкаталог <code>.bzr</code> вверху
|-
| Модель
|
| Простая модель ветвлений (ветка=клон)
| Простая модель ветвлений (ветка=клон)
|-
| Особенности репозиториев
|
|
| Разделяемые репозитории для совместного использования ревизий в разных ветках [http://bazaar-vcs.org/BzrVsGit Supposed-to-be Better Storage Model]
|-
| Версионирование каталогов
| {{No}}
| {{No}}
| {{Ok}}
|-
| Подмодули
| {{Ok}} <code>[http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html git-submodule]</code>
| {{Ok}} [http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension Forest extension] ([http://blogs.sun.com/kto/entry/openjdk_mercurial_forest as used by OpenJDK]
| {{Caution}} Решаемо через сторонние инструменты [http://bazaar-vcs.org/ConfigManager ConfigManager]
|-
| Индивидуальные коммиты для отдельного файла
| {{No}} Противоречит архитектуре
| {{No}} Противоречит архитектуре
| {{No}} Противоречит архитектуре
|-
| Rebase/Queue
| {{Ok}} [http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html <code>rebase</code>]
| {{Ok}} [http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension Mercurial Queues]
| {{Ok}} [http://bazaar-vcs.org/Rebase Rebase plugin], [http://blogs.gnome.org/jamesh/2008/04/01/bzr-loom/ Loom plugin] ([http://bazaar-vcs.org/Documentation/LoomAsSmarterQuilt comp. with Quilt])
|-
| Web-доступ
|
|
|
|-
|
| {{Ok}} {{Note}} Read-only доступ можно дать публикацией статических файлов по HTTP.
| {{Ok}} {{Note}} Read-only доступ можно дать публикацией статических файлов по HTTP.
| {{Caution}} Не так хорошо. Теперь доступен более быстрый [http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#running-a-smart-server Smart Server].
|-
|
| gitweb, wit, cgit
| hgweb (single rep), hgwebdir (multi rep)
| webserve, trac, [http://www.lag.net/loggerhead/ Loggerhead]
|-
| Интеграция
|
|
|
|-
| Интеграция (API)
| {{No}} Скорее скриптуем, чем API-интегрируем (хотя есть некий заброшенный API-frontend: [http://repo.or.cz/w/rubygit.git Ruby/Git])
| {{Ok}}
| {{Ok}} Богатый API
|-
| Миграция
| {{Ok}} Хороша. <code>[http://www.kernel.org/pub/software/scm/git/docs/git-svn.html git-svn]</code> тоже весьма мощная штука, представляет двухсторонний прокси между ''Subversion'' и ''Git'', позволяет исползовать ''Git'' поверх существующего репозитория ''Subversion''.
| {{Ok}} Хороша. Но <code>[http://pypi.python.org/pypi/hgsvn hgsvn]</code> не настолько отлажен, как <code>git-svn</code>.
| {{Caution}} Неплохо реализована, но медленная.
|-
| Интеграция с ''Issue''-трекерами
| {{Caution}} Есть для [[Trac]], паллиатив для [[Bugzilla]]. Для [[JIRA]] увы нет.
| {{Ok}} Есть для [[Trac]], [[Bugzilla]], [[JIRA]].
| {{Caution}} Есть для [[Trac]] и [[Bugzilla]], нет для [[JIRA]].
|-
| Плагины к IDE
| {{Ok}} <tt>Idea</tt>, <tt>Eclipse</tt>, <tt>NetBeans</tt>
| {{Ok}} <tt>Idea</tt>, <tt>Eclipse</tt>, <tt>NetBeans</tt>, <tt>MS Visual Studio([http://visualhg.codeplex.com/ VisualHG], [http://www.newsupaplex.pp.ru/hgscc_news_eng.html hgcc])</tt>
| {{Caution}} <tt>Idea</tt>, <tt>Eclipse</tt>. Нет для <tt>NetBeans</tt>
|-
| Плагины
| {{Ok}} <tt>Emacs</tt> / <tt>Vim</tt> / …
| {{Ok}} <tt>Emacs</tt> / <tt>Vim</tt> / …
| {{Ok}} <tt>Emacs</tt> / <tt>Vim</tt> / …
|-
| Производительность
|
|
|
|-
|
| {{Ok}} <tt>git</tt> всегда был быстрее
|
| {{No}} <tt>bzr</tt> всегда самый медленный из этой троицы.
|-
| Навороты
|
|
|
|-
|
| {{Ok}} С 150 выполняемыми файлами-командами нетрудно найти любую суперкоманду, о которой вы всегда мечтали (хотя это конечно увеличивает сложность)
|
|
|-
| Сложность
|
|
|
|-
|
|
|
| <tt>Bzr</tt> декларирует скрытие сложности поддержанием четкого и ясного пользовательского интерфейса, при этом адаптируясь к различным моделям взаимодействия [http://bazaar-vcs.org/Workflows workflows] и даже их эволюции в каждой команде.
|-
| Именование версий/ревизий
| {{No}} Ревизии — SHA-1 хеши, что не особо юзер-френдли, если например, запрашивать различия между версиями. Так сделано, чтобы гарантировать надежность и целостность данных, а также чтобы избежать конфликтов при слиянии с другими участниками.
| {{Ok}} Простое именование
| {{Ok}} Простое именование: <tt>r1</tt>, <tt>r2</tt>, <tt>etc</tt>…
|-
| Команды
| {{Caution}} Понятные, за рядом исключений типа команды <code>rename</code>, которая отличается от других SCM (и уже не поменяют из-за поддержки обратной совместимости). <tt>git</tt> это наиболее навороченная по командам СУВ, но очень сложно овладеть полным набор всех его команд и опций.
Существование инструментов типа [http://www.gnome.org/%7Enewren/eg/ Easy Git] только подтверждает исключительную сложность <tt>Git</tt>.
| {{Ok}} Понятные (похожие на команды <tt>Subversion</tt>)
| {{Ok}} Понятные
|-
| Число пользователей
|
|
|
|-
|
| {{Ok}} Большое / Много (и крупных) проектов на <tt>git</tt><ref>См.
* http://git.or.cz/gitwiki/GitSurvey2007
* http://git.or.cz/gitwiki/GitSurvey2008
* http://git.or.cz/gitwiki/GitSurvey2009</ref>
| {{Ok}} Большое / Много (и крупных) проектов на <tt>hg</tt>.
| {{No}} Меньше предыдущих: кроме проектов Canonical (Ubuntu, Launchpad), особо крутых проектов нет.
|-
|
| Linux kernel, Cairo, Wine, X.Org, Rails, Rubinius, Compiz Fusion
| Xine, OpenJDK, OpenSolaris, NetBeans, (Part of) Mozilla
| Ubuntu (частично), Launchpad
|-
| Документация
| {{Ok}} Хороша. Хороший <tt>man</tt> с кучей примеров.
| {{Ok}} Хороша.
| {{Ok}} Хороша.
|-
| Платформы
|
|
|
|-
|
| {{Caution}} Плохая Windows-поддержка
| {{Ok}} Кроссплатформенный
| {{Ok}} Кроссплатформенный
|-
| {{Ok}} Полезные особенности
|
|
|
|-
|
| <tt>git</tt> скорее скриптуем, чем расширяем, что с одной стороны хорошо, а с другой — плохо. Легко использовать из скрипта, например, все тесты можно сделать из <tt>bash</tt>. Весьма настраиваем в продвинутом администрировании:
* Промежуточные области <ref>Промежуточные области, ''staging area'' или ''index'' — оригинальная концепция <tt>git</tt>, расширяющее стандартный двудольный подход РабочаяКопия-Репозитарий, еще одной промежуточной областью, в которой можно решать в какие именно изменения и в каком порядке пойдут в репозитарий: http://whygitisbetterthanx.com/images/index1.png http://gitready.com/beginner/2009/01/18/the-staging-area.html</ref>,
* Заброшенные объекты <ref>Заброшенные объекты — ''dangling objects'' (слепки файлов, так и не ставших частью ни одного коммита, см. http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#dangling-objects)</ref>,
* detached heads<ref>''Detached heads'' — концепция работы не с последними версиями каждой ветви, а с произвольными коммитами на стволе. http://sitaramc.github.com/concepts/detached-head.html</ref>,
* plumbing vs porcelain<ref>''plumbing vs porcelain'' — вероятно автор имел ввиду существование низкоуровнего, сантехнически-канализационного уровня <tt>git</tt>, для построения собственного фреймворка управления версиями, так и высокоуровнего «мойдодырного» пользовательского уровня</ref>,
* reflogs <ref>reflogs — http://www.kernel.org/pub/software/scm/git/docs/git-reflog.html</ref>.

Возможны локальные (внутрирепозитарные) ветки.
| [http://www.markshuttleworth.com/archives/126 Robust Renaming].
| [http://www.markshuttleworth.com/archives/126 Robust Renaming]. Поддержка легких ''checkouts'' (без истории). [http://bazaar-vcs.org/BzrUsingBoundBranches Bound branches]. Возможны локальные (внутрирепозитарные) ветки. [https://launchpad.net/pqm Patch Queue Manager] (управление несколькими ветками, выполнение слияний для разработчиков)
|-
| {{Ok}} Несколько крутых команд/расширений
|
* <code>[http://www.kernel.org/pub/software/scm/git/docs/git-stash.html git-stash]</code> (поддержка прерывания для краткого баг-фикса в другом проекте),
* <code>[http://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html git-cherry-pick]</code> (для выбора отдельных коммитов, без полных веток),
* <code>[http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html git-rebase]</code> «Quilt-like changeset» типа [http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension Mercurial Queues]).
* <code>git add -i</code> аналог ''Mercurial RecordExtension''.

Похоже тут есть все команды, которые вы бы могли захотеть.
|

* [http://www.selenic.com/mercurial/wiki/index.cgi/RecordExtension RecordExtension] — позволяет выбрать, какую часть изменений рабочего каталога вы собираетесь закоммитить.
* [http://www.selenic.com/mercurial/wiki/index.cgi/ShelveExtension Hg Shelve Extension] — аналог <tt>git-stash</tt>: — интерактивно выбрает изменения, чтобы их «обойти».
|

* [https://launchpad.net/shelf Shelf] — аналог <tt>git-stash</tt>: поддержка прерывания для краткого баг-фикса в другом проекте, но похоже помирает — последнее изменение в марте 2007.
* [https://launchpad.net/bzr-dbus bzr-dbus] — для броадкаста ревизий и триггеров.
|-
| {{No}} Проблемы
|
|
|
|-
|
|

* [http://www.markshuttleworth.com/archives/126 Переименование не так хорошо, как в bzr]
<ref>
См. например [http://automatthias.wordpress.com/2007/06/07/directory-renaming-in-scm/ Test Case]. Переводчик экспериментировал с
* svn 1.6.6
* bzr 2.0.2
* hg 1.4.1
* git 1.6.5.2
* darcs 2.3.0

<tt>git</tt> и <tt>svn</tt> тест не прошли.
</ref>.
* Настройка статического <tt>read-only</tt> HTTP-доступа слегка туповата (<tt>--bare</tt> и <tt>update-server-info</tt>).
* Обработка файлов в ''Unicode'' (UTF-16).
* Модель хранения. <tt>Git</tt> хранит каждый отдельный объект как отдельный файл, без обязательного вычисления дельты между ревизиями (это делает отдельная команда). Обязательно настройте, чтобы регулярно запускалась команда <tt>pack</tt>.
* Мешанина из <tt>C</tt>, <tt>Perl</tt> и скриптов на <tt>bash</tt>, что очень затрудняет полноценный перенос на другие системы.
|

* <s>[http://www.markshuttleworth.com/archives/126 Renaming not handled as good as bzr]. [FIXED]</s>
* Нет локальных веток, нужно использовать клон. Чтобы сэкономить место, <tt>Hg</tt> использует ''hardlinking'', из-за чего возникают проблемы при <tt>pull</tt> (и еще под Windows).
* Расширение «Forest» (для подмодулей) неродное, и плохо документировано.
|
|-
| GUI
|
|
|
|-
| Windows
| <s>{{No}}</s> Уже не так все плохо<ref>Появился и развивается «черепаховый» интерфейс — [http://code.google.com/p/tortoisegit/ TortoiseGit]</ref>
| {{Ok}} [http://www.selenic.com/mercurial/wiki/index.cgi/TortoiseHg TortoiseHg]
| {{Caution}} Сложновато. <s>TortoiseBzr (нет коммитов после Aug 2007, хотя проект пока [http://doc.bazaar-vcs.org/bzr.dev/developers/tortoise-strategy.html жив])</s><ref>Все развивается, более того, TortoiseBzr входит в стандартный windows-дистрибутив Bzr</ref>. <s>[http://sorn.net/blog/2008/04/Windows-Installer-for-Wildcat-BZR WildcatBZR]</s><ref>Увы, проект https://launchpad.net/wildcat-bzr похоже заброшен.</ref>.
|-
| Linux
| {{Ok}} <tt>gitk</tt>, <tt>git-gui</tt>, <tt>tig</tt>, …
| {{Ok}} <tt>TortoiseHg</tt>, <tt>Hgtk</tt>, <tt>hgct</tt>
| {{Ok}} <tt>bzr-gtk</tt>, …
|-
| Инсталляция
|
|
|
|-
|
| {{Caution}} Нужен либо <tt>cygwin</tt> либо специальный <tt>git</tt>-дистрибутив типа [http://code.google.com/p/msysgit/ Git on MSys]
| {{Ok}}
| {{Ok}}
|-
| Бесплатные хостинги
|
|
|
|-
|
| [http://github.com/ GitHub], [http://gitorious.org/ gitorious]
| <s>[http://freehg.org/ FreeHg]</s><ref>http://freehg.org/ увы помер, но вместо него есть http://bitbucket.org/ !</ref>
| [https://launchpad.net/ Launchpad]
|}

{{caution}} Полно еще споров, например, от том, что каталоги в <tt>Bzr</tt> это [http://bazaar-vcs.org/BzrVsGit#head-8d6788e5fb366d04efa536c4c41d4b36e67233fb ветки, а не контейнеры веток], как в <tt>git</tt>.

<s>А то, что Mercurial использует внешние инструменты для слияний, [http://bazaar-vcs.org/BzrVsHg#head-a1fbb925120017d8d4b05a2da1eba9469ab48160 критикуют стороники Bazaar]</s>. Это исправлено с версии [http://www.selenic.com/mercurial/wiki/index.cgi/MergeToolConfiguration Mercurial v1.0].

Есть и другие нексколько предвзятые сравнения от Bazaar-команды:
* [http://bazaar-vcs.org/BzrVsGit Bazaar vs Git],
* [http://bazaar-vcs.org/BzrVsHg Bazaar vs Mercurial]

и соответственно, ответ на это:
* [http://www.selenic.com/mercurial/wiki/index.cgi/BzrVsHg reply from Mercurial].

[[Image:Gitsurvey.png|center|framed|Some User Statistics from Git Survey 2007]]

{{caution}} Обратите внимание, что в этом отчете не было возможности выбрать ''Ruby'', неплохо было бы добавить его в опрос 2008 года<ref>Ruby добавлен в отчет 2008 года, и показал там очень большой результат — второе место с 43 % (См. [http://git.or.cz/gitwiki/GitSurvey2008])</ref>.

{{note}} Очень забавно, что треть людей используют DVCS взаимодействуюя с … 0 или 1 участниками!<ref>Пошлая шутка от [[User:StasFomin|переводчика]] — «…согласно опросу среди любителей группового секса, 70 % имеет 1 полового партнера, а 29.9 % оставшихся — 0…»</ref>.

=== GUI ===

Графический интерфейс ко всем системам хороший и примерно одинаковый, хотя <tt>gitk</tt> наверное эффективней.

<tt>TortoiseHg</tt> (с активированной опцией «folder watch») сильно тормозит на больших репозиториях, типа Мозилловского.

[[Image:gitk.png|center|framed|gitk on Linux]]
[[Image:tortoise-hg.png|center|framed|TortoiseHg on Windows]]
[[Image:olive-bzr-gtk.png|center|framed|OliveGtk on Linux]]

=== Краткий взгляд на производительность (не претендует на истину в последней инстанции) ===

<tt>git</tt> по прежнему лидирует в битве за производительность, но <tt>Hg</tt> и <tt>Bzr</tt> существенно улучшились за последний год.

Обратите внимание, что Mercurial удваивает количество файлов в вашем репозитории (история хранится по-файлово в <code>.hg/store/data</code>).
Это не шибко хороший выбор для Windows-систем, живущих на NTFS.

Также интересно видеть, что у <tt>git</tt> большое преимущество за счет операционной системы при выполнении команд.
<tt>Hg</tt> и <tt>Bzr</tt> не тратят большую часть времени в системных вызовах, а <tt>Git</tt> проводит в них до <tt>10-40 %</tt> времени.
Возникает ожидаемый вопрос, о том, будет ли его производительность также хороша под Windows, где <tt>git</tt>-разработчики не имеют доступа к ко всем возможностям системы, как у них было под Linux.

Надо тестировать как отдельные слияния, так и слияние очередями, это связанная часть тестов.

Бенчмарки надо также гонять под Windows, ибо:
# Даже если ваш сервер работает на <tt>*nix</tt>, многие разработчики по прежнему живут под Windows, и основная DVCS-работа идет именно у разработчиков под Windows.
# Производительность под виндами точно должна отличаться.

[[Image:DVCS-benchs.png|center]]

См. [[#Условия тестов]]

== Когда? ==

=== Истории использования ===

==== Kelly O’Hair ====
Мне удалось расспросить [http://java.sun.com/developer/Meet-Eng/ohair/ Kelly O’Hair] из Sun на тему его выбора Hg для OpenJDK.

{{question}} Я прочел [http://blogs.sun.com/kto/entry/mercurial_openjdk_questions причины] перехода с <tt>TeamWare</tt> на <tt>Mercurial</tt>, но остались вопросы. Вы просто последовали за выбором проекта ''OpenSolaris''?

{{note}} Ну, в некоторой степени да, но выбор для ''OpenSolaris'' стал также очень распространенным выбором в Sun для всех команд разработчиков желающих куда-нибудь смигрировать. Исследование для ''OpenSolaris'' было впечатляюще исчерпывающим, и их требования в точности совпадали с нашим. Ну а так как нам надо было куда-то переезжать с ''OpenJDK'', так как ''TeamWare'' для open-source проекта не подходит, выбор ''Mercurial'' стал для нас вполне очевидным.

{{question}} А вы пробовали освежить сравнение, и снова попробовать другие DVCS-системы (git, и т. п.)?

{{note}} Нет, мы не занимались перепроверкой, это наверно пустая трата времени. Единственной альтернативной на мой взгляд был <tt>git</tt>, но там не уделяли достаточно внимания работоспособности под Windows, а это нам было нужно. Так что повторюсь, выбор был очевиден.

{{question}} Так ведь [http://www.opensolaris.org/os/community/tools/scm/on-scm-tools/ отчету для ''OpenSolaris''], который был опубликован в апреле 2006, уже два года стукнуло…

{{note}} Да знаю я. Что-то поменялось, git обновился, но Земля вертится, и ''Mercurial'' тоже улучшился.

{{question}} Какие особые проблемы встретились вам при миграции?

{{note}} Права и владения файлами могут быть проблемой при разделении репозитария через сетевые файловые системы, типа NFS или UFS, так что мы в конец концов настроили нормальный сервер для работы с разделяемыми репозитариями, так лучше. Это несложно.

Еще мы столкнулись с проблемой, что использование триггеров (''hooks'') для отката или фильтрации ''push''-изменений создает некоторое временное окно, в течении которого кто-то может вытащить (''pull'') изменения, которые должны быть откачены. В результате мы завели пару репозитариев — один для публикации изменений (''push''), другой — для извлечения (''pull''), и настроили между ними автоматическую синхронизацию, которая срабатывала после выполнения всех триггеров.

Использование лесов (''forests'') также приводило к проблемам, так как ''forest-push'' по сути набор отдельных push-операций, и если одна из них падает, то по уму надо бы откатить и все остальные. Однако никто этого не делает, все надеются на удачу.
Впрочем, если репозитории в лесе достаточно независимы, это не будет реальной проблемой.

{{question}} И как оно в повседневном использовании?

{{note}} Поживем — увидим. Такие изменения кому-то даются легко, кому-то — тяжело. Дайте время, я думаю большинство привыкнет и даже выучится это любить.

Понятие «рабочих наборов файлов» (''working set files'', с чем работает <tt>hg update</tt>) и необходимость интеграции ''changeset''-ов, которые непонятно с чем сливать, путает народ. Также идея пересылать ''changeset''-ы а не отдельные файлы, для некоторых людей приводит к проблеме «Почему нельзя просто переслать вот этот вот один файл?».

{{question}} И чем это лучше, чем ''TeamWare''?

{{note}} Много-много-много быстрее чем TeamWare. В перспективе наши команды в Китае и России перейдут на единую инфраструктуру сборки и интеграции, так как им не потребуется держать зеркала для серверов интеграции. Обновления (''pulls'') очень быстры даже при медленных соединениях.

Состояние репозитория в Mercurial достаточно целостное, в отличие от ''TeamWare'', который разрешал частичные workspac-ы, да и вообще TeamWare всего лишь дырявая авоська с индивидуально учитываемыми (SCCS-) файлами.

Понятие набора изменений (''changeset'') в TeamWare отсутствует, вместе с понятием определенного состояния репозитария целиком (то есть просто ''id''-а, ''changeset''-а).

{{question}} Так есть что-то, что вам не хватает от ''TeamWare''?

{{note}} Ребятам не хватает оповещений через email, и еще истории транзакций «putback/bringover», хотя многое из этого можно вытащить из ''changeset''.
Возможно еще не хватает чего-то типа истории транзакций с репозиторием, но опять таки, почтовых архивов событий от Mercurial было бы достаточно.

{{question}} Так <tt>Hg</tt> стал избранной Sun-ом СУВ для всего, включая внутренние проекты? Или Sun использоует ее только для публичных проектов, которым требуется открытость?

{{note}} Да мы все проекты переносим, как внутренние, так и внешние, там где это имеет смысл разумеется. Вижу, что растет интерес решившихся на это проектов.

==== Pierre d’Herbemont ====

Также мне удалось расспросить на тему <tt>git</tt> и ''Pierre d’Herbemont'' из [http://www.videolan.org/vlc/ VLC].

{{question}} Для начала, какую систему управления версиями вы использовали до <tt>git</tt>?

{{note}} SVN, затем зеркало <tt>git-svn</tt>.

{{question}} А когда вы мигрировали?

{{note}} Мы открыли git-зеркало для svn-репозитория, чтобы облегчить участие VLC в ''Google Summer of Code''. Это что предшествало этому. Затем мы полностью мигрировали на <tt>git</tt> 1-2го марта 2008.

{{question}} А почему вы выбрали Git, а не его конкурентов?

{{note}} По пунктам:
* Лучше SVN: Git быстр. Ветка дешевая. Атомарные коммиты<ref>Удивительная претензия к SVN, в котором это есть (''примечание переводчика'').</ref>. Можно делать ''rebasing'' относительно вершины другого дерева.
* Лучше других DVCS: Проверенная пользовательская база (''Linux Kernel''). Я успешно использовал его, когда работал над ''Wine''. Git sexy. И несколько ключевых разработчиков имело опыт с ''Git'', и никто с Mercurial или чем-то подобным. Вобщем, тут не технические соображения сработали.

{{question}} Были у вас какие-нибудь специфические проблемы с миграцией? А с ежедневным использованием?

{{note}} Были проблемы с <tt>Trac</tt> и <tt>buildbot</tt>. У них поддержка Git была минимальной, особенно в их релизных версиях. Нам пришлось вытаскивать последние версии ''Builbot'' из исходников. Для ''Trac'' мы использовали убогий Git-плагин, который требовал <tt>Trac 0.11</tt>. Но <tt>Trac 0.11</tt> еще не стабилен, там есть несколько известных утечек памяти, которые удерживают нас от переключения. В общем, мы ждем, когда они это починят…

Некоторым контрибьюторам требуется некоторое время, чтобы освоится с Git. Но через пару дней, все оказывается в порядке.

И многие git-ньюбы начинают действительно им наслаждаться.

== Ну и что? ==

Выбор между распределенными и централизованными СУВ далек от простоты.
DVCS определенно изменят практику вашей работы, как индивидуальной, так и командной.

''Subversion'', один из лидеров CVCS [http://blog.red-bean.com/sussman/?p=79 не сдается]<ref>Мы сделали переводы этих статей, см. [[:Категория:Статьи о Subversion]]</ref> и в производительности, и по функционалу и [http://subversion.tigris.org/roadmap.html версия 1.5] уже должна быть неплохим компромиссом. Он может рассчитывать на существущих пользователей и дух простоты (за счет некоторых неудобств). В определенных случаях, как например в работе с большими бинарными файлами, ''Subversion'' должен быть лучше, чем DVCS так как пространство под рабочии копии остается неизменным. Также он эффективней, если вы активно используете частичные ''checkout''-ы, (хотя если это происходит часто — это явная проблема недостаточного разбиения вашего проекта на модули).

Даже если вы сделаете свой выбор в пользу DVCS или CVCS, то будет сложно сравнить конкурентов в выбранной области, то есть реализация (например, команды) и соответственно их производительность, будет существенно отличаться. Нет ни одного теста производительности даже для общих операций.
В этой жесткой битве, ''Bazaar'' потерял многих, очень важных и влиятельных ранних пользователей-энтузиастов (Mozilla, Solaris, OpenJDK) из-за плохой начальной производительности.
Еще стоит заметить, что вебсайт Bazaar был слишком «маркетинговым»: публиковались не совсем честные сравнения с конкурентами, или тесты производительности по отдельным параметрам, в которых система превосходила конкурентов (см. например [http://bazaar-vcs.org/Benchmarks/SpaceEfficiency Space efficiency]), при том, что не было сравнений по времени для ежедневных команд: <tt>diff</tt>, <tt>add</tt>, …
Мне кажется, что хотя все эти три проекта стартовали примерно в одно и то же время, <tt>bzr</tt> с самого начала столкнулся с множеством проблем в производительности и архитектуре, что привело к тому, что он сейчас чуть менее зрел и надежен, чем его конкуренты.

И еще ранее не наблюдавшийся феномен — похоже, что многие делают выбор в зависимости от языка программирования сообщества:
* Java и разработка связанная с Sun более интересуется <tt>Mercurial</tt>
* C/Linux/Ruby/Rails -проекты сооблазняются <tt>git</tt>.

Надеюсь, эта статья вас просветила, и я всегда рад узнать о вашем опыте и иным отзывам!

=== Благодарности ===
Благодарю тех, кто любезно согласился на мое интервью: ''Kelly O’Hair'', ''Pierre d’Herbemont''.
''Ian Clatworthy'' за его оперативную помощь в преобразовании hg-репозитория Mozilla в <tt>Bzr</tt>.

IRC-каналы #git, #mercurial, #bzr на Freenode IRC, #mozilla на Mozilla IRC.
Картинка с бегунами от [http://flickr.com/photos/antoniojuez/384183109/ Antonio Juez].

=== Случайные цитаты ===
;Linus Torvald:
:* «Subversion has been the most pointless project ever started».
:* «If you like using CVS, you should be in some kind of mental institution or somewhere else»<ref>См. наш перевод этой речи Линуса Торвальдса — [[Линус Торвальдс о GIT на Google Talks]]</ref>.

;Mark Shuttleworth (Ubuntu / Canonical Ltd.):
:* «Merging is the key to software developer collaboration».

;Ian Clatworthy (Canonical / Bazaar):
* «By 2011—2012, I predict this technology will be widely adopted and many teams will wonder how they once managed without it.»

;Assaf Arkin в [http://blog.labnotes.org/2008/04/30/git-forking-for-fun-and-profit/ Git forking for fun and profit originally]: «Apache built a great infrastructure around SVN, lots of sweat and tears went into making it happen, and at first I felt like we’re circumventing all of that. But the longer I thought about it, the more I realized that Git is just more social than SVN, and that’s exactly what Apache is about.»

Статья была обновлена 2008-05-12 после коммантариев от [http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/41384 Ian Clatworthy] и портала [http://reddit.com/r/programming/info/6iiny/comments/ reedit].
* Добавлены плагины Bzr и Windows GUI: <tt>rebase</tt>, …, <tt>Wildcat BZR</tt>, …
* Добавлен <tt>Hg Shelve</tt>.
* Обновлены SLOC для Hg (надо было еще учесть HTML-документацию, и оставил <tt>contrib</tt>, отвественный за поддержку Lisp и Tcl/Tk).
* Обновлен размер репозитория для <tt>git</tt> после правильной команды <tt>repack</tt> (<code>git repack -a -f -d --window=100 --depth=100</code> после которой размер стал постоянным) (Спасибо за комментарий ''dhamma vicaya'').

=== Извинения ===
[http://darcs.net/ darcs], [http://monotone.ca/ Monotone]! Простите, что не рассматривал вас в этом сравнении, так как мне и так пришлось неслабо поработать чтобы собрать всю эту информацию и протестировать эти три DVCS. Да, странно получилось, что хотя вы самые старые на DVCS-сцене, актуальны теперь в основном те DVCS, которых я рассматривал тут (конечно, вряд ли эта ситуация измениться, но добро пожаловать пользователям <tt>darcs</tt> и <tt>Monotone</tt> с комментариями и рекламой!).

== Ссылки ==

* Очень исчерпывающие [http://en.wikipedia.org/wiki/Git_%28software%29 Wikipedia page about Git].
[http://en.wikipedia.org/wiki/Revision_control#Distributed_revision_control Distributed Revision Control Wikipedia page].
[http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison of Revision Control Software Wikipedia page].

* [http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf Distributed Version Control — Why and How ] от Ian Clatworthy, ''Canonical'' (Bazaar).

* [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated)].

* [http://www.dribin.org/dave/blog/archives/2007/12/28/dvcs/ Distributed Version Control Systems] от ''Dave Dribin'', который в конце концов выбрал [http://www.dribin.org/dave/blog/archives/2007/12/30/why_mercurial/ выбрал Mercurial].

* [http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php Why Distributed Version Control].

* [http://www.opensolaris.org/os/community/tools/scm/ Source Code Management for OpenSolaris]. [http://www.opensolaris.org/os/community/tools/scm/history/ OpenSolaris SCM Project History] (2005).

* [http://blogs.sun.com/kto/entry/mercurial_openjdk_questions Mercurial OpenJDK Questions] от ''Kelly O’Hair'', ''Sun''.
* [http://plasmasturm.org/log/487/ Why I chose git].
* [http://live.gnome.org/DistributedSCM Distributed SCM] от команды Gnome.
* [http://wiki.freebsd.org/VersionControl FreeBSD SCM Requirements].
* [http://wiki.services.openoffice.org/wiki/SCM_Requirements Open Office Requirements].
* [http://wiki.mozilla.org/Version_Control_System_Requirements Mozilla VCS Requirements].
* [http://texagon.blogspot.com/2008/02/use-mercurial-you-git.html Use Mercurial you git!] от ''Ian Dees''.
* [http://www.dehora.net/journal/2008/04/06/what-a-dvcs-gets-you-maybe/ What a DVCS gets you (maybe)] от ''Bill de hÓra''.
* [http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/ The Differences Between Mercurial and Git].

Ну и все URLы, так или иначе упомянутые в этой статье.

=== Шпаргалки ===

* [http://ktown.kde.org/%7Ezrusin/git/git-cheat-sheet-medium.png Git Cheat Sheet]
* [http://mercurial.selenic.com/wiki/QuickReferenceCardsAndCheatSheets  Mercurial Cheat Sheets]
* [http://doc.bazaar-vcs.org/bzr.1.3/en/quick-reference/quick-start-summary.pdf Bazaar Quick Start Card]

=== Условия тестов ===
''Benchmark conditions''

Тесты были проведены с использованием:
* <tt>AMD Athlon™ 64 Processor 3500+</tt>
* <tt>1GB RAM</tt>
* <tt>Linux Kubuntu 6.10 Edgy x86_64 with ext3 fs</tt>.

Каждую команду запускали <tt>8</tt> раз, с отбрасыванием лучшего и худшего времени. Все это выполнялось локально, через файловую систему (надо конечно протестировать и остальные протоколы, ведь даже если DVCS не связана с центральным сервером, плохо реализованное сетевое взаимодействие существенно ухуджит и производительность пользователей.

Использовались следующие версии:

* [http://www.selenic.com/pipermail/mercurial/2008-March/018014.html Mercurial 1.0 released] от <tt>2008-03-24</tt> (c [http://www.selenic.com/mercurial/bts/issue1050 Issue 1050 patch] опцией «Edgy inotify»)
* [http://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.5.5.txt Git 1.5.5] от 2008-04-08
* [http://doc.bazaar-vcs.org/bzr.1.2/en/release-notes/NEWS.html Bazaar 1.3.1] от 2008-04-10

Репозиторий содержал слепок из 12456 ''changeset''-ов (от 20080303, 70853 полных версий из hg-репозитория), ≈30000 файлов из репозитория Mozilla (изначально они были в hg-формате и сконвертированы в git-репозиторий с помощью <tt>hg-fast-export.sh</tt>, и
в Bazaar-репозиторий с помощью <tt>hg-fast-export.sh</tt> плюс плагин <tt>fast-import</tt>).
Для репозиториев использовались файловые форматы по умолчанию, и размер репозитория <tt>git</tt> оставался постоянными, при запуске <tt>git-gc</tt> (что в общем, считается нормальным для свежемигрировавшего репозитория). Правился один файл (<code>dom/src/base/nsDOMClassInfo.cpp</code>), точно как в [http://weblogs.mozillazine.org/jst/archives/2006/11/vcs_performance.html тесте проводимом ''Jst'' полтора года назад].

== Примечания ==
<references/>


{{replicate-from-custiswiki-to-lib}}
[[Категория: Системы контроля версий]]