Distributed Version Control Systems: A Not-So-Quick Guide Through

Короткая ссылка: DVCS-A Not-So-Quick Guide

Ссылки сюда (1) →

Перевод статьи «Distributed Version Control Systems: A Not-So-Quick Guide Through» от Sebastien Auvray с портала InfoQ.

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

К моменту перевода прошел уже год, и многие положения статьи изменились — самые очевидные исправлены переводчиком (Стас Фомин) (в частности, исправлены битые ссылки), часть снабжены сносками, указывающими на произошедшие изменения.

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

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

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

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

С тех пор выросло множество СУВ, различным образом улучшающих CVS:

• Subversion (2000);
• Perforce (1995);
• CVSNT (1998)…

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

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

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

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

• Mercurial (апрель 2005);
• Bazaar (март 2005);
• darcs (ноябрь 2004);
• Monotone (апрель 2003).

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

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

Вот в чем обвиняют Subversion:

• Главное: ветвится стало легко, но слияние-то по-прежнему мучительно (а ведь зачем «ветвление без слияний?»). Наверняка во всех проектах вам придется развлекаться с ветками разработки и тестирования. А у Subversion нет «безопасного повторного» слияния, пользователей заставляют вручную отслеживать интервалы ревизий, которые уже были интегрированы в другие ветки, и все это разумеется подвержено ошибкам.
• Никак не послать изменения другому пользователю минуя центральный сервер.
• Subversion не может интегрировать измененения при переименовании файлов или каталогов.
• Нужно специально придерживаться «trunk/tags/branches»-соглашения о ветках (См. misleading).
• Нет оффлайн-коммитов.
• Подкаталоги .svn замусоривают рабочую копию.
• Обработка свойства svn:external может быть опасна.
• Производительность: Performance

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

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

Как?

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

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

Это приводит к сущетвенным отличиями и преимуществам над централизованными системами:

По умолчанию нет канонической, рекомендованной копии

только рабочие копии.

Оффлайн операции

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

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

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

Для введения в непосредственно практики DVCS-разработки, можете взглянуть на статьи Intro to Distributed Version Control (Illustrated) или возможно Collaboration workflows.

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

Кто?

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

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

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

Для простоты, приведем сначала общие свойства всех трех систем:

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

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

	git	Mercurial	Bzr
	http://git.or.cz/	http://www.selenic.com/mercurial/	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
Версия	> 1.0 (1.6.5.1)	> 1.0 (1.3.1)	> 1.0 (2.0.0)
Запуск проекта	апрель 2005	апрель 2005	март 2005
Реализация
SLOC (без тестов)
SLOC Count	130550	38172	79864
Покрытие тестами (% исходников относящихся к тестам)	~20 %	~25 %	~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
Подпись ревизий			Частично/Ручная проверка
Слияние изменений
EOL-соглашения			Запланировано в 1.6
Интернационализация
Частичный checkout	Используйте вместо этого подмодули	Запланировано	Запланировано
Модель / Архитектура
Файлы	Один подкаталог .git вверху	Один подкаталог .hg вверху	Один подкаталог .bzr вверху
Модель		Простая модель ветвлений (ветка=клон)	Простая модель ветвлений (ветка=клон)
Особенности репозиториев			Разделяемые репозитории для совместного использования ревизий в разных ветках Supposed-to-be Better Storage Model
Версионирование каталогов
Подмодули	git-submodule	Forest extension (as used by OpenJDK	Решаемо через сторонние инструменты ConfigManager
Индивидуальные коммиты для отдельного файла	Противоречит архитектуре	Противоречит архитектуре	Противоречит архитектуре
Rebase/Queue	rebase	Mercurial Queues	Rebase plugin, Loom plugin (comp. with Quilt)
Web-доступ
	Read-only доступ можно дать публикацией статических файлов по HTTP.	Read-only доступ можно дать публикацией статических файлов по HTTP.	Не так хорошо. Теперь доступен более быстрый Smart Server.
	gitweb, wit, cgit	hgweb (single rep), hgwebdir (multi rep)	webserve, trac, Loggerhead
Интеграция
Интеграция (API)	Скорее скриптуем, чем API-интегрируем (хотя есть некий заброшенный API-frontend: Ruby/Git)		Богатый API
Миграция	Хороша. git-svn тоже весьма мощная штука, представляет двухсторонний прокси между Subversion и Git, позволяет исползовать Git поверх существующего репозитория Subversion.	Хороша. Но hgsvn не настолько отлажен, как git-svn.	Неплохо реализована, но медленная.
Интеграция с Issue-трекерами	Есть для Trac, паллиатив для Bugzilla. Для JIRA увы нет.	Есть для Trac, Bugzilla, JIRA.	Есть для Trac и Bugzilla, нет для JIRA.
Плагины к IDE	Idea, Eclipse, NetBeans	Idea, Eclipse, NetBeans, MS Visual Studio(VisualHG, hgcc)	Idea, Eclipse. Нет для NetBeans
Плагины	Emacs / Vim / …	Emacs / Vim / …	Emacs / Vim / …
Производительность
	git всегда был быстрее		bzr всегда самый медленный из этой троицы.
Навороты
	С 150 выполняемыми файлами-командами нетрудно найти любую суперкоманду, о которой вы всегда мечтали (хотя это конечно увеличивает сложность)
Сложность
			Bzr декларирует скрытие сложности поддержанием четкого и ясного пользовательского интерфейса, при этом адаптируясь к различным моделям взаимодействия workflows и даже их эволюции в каждой команде.
Именование версий/ревизий	Ревизии — SHA-1 хеши, что не особо юзер-френдли, если например, запрашивать различия между версиями. Так сделано, чтобы гарантировать надежность и целостность данных, а также чтобы избежать конфликтов при слиянии с другими участниками.	Простое именование	Простое именование: r1, r2, etc…
Команды	Понятные, за рядом исключений типа команды rename, которая отличается от других SCM (и уже не поменяют из-за поддержки обратной совместимости). git это наиболее навороченная по командам СУВ, но очень сложно овладеть полным набор всех его команд и опций. Существование инструментов типа Easy Git только подтверждает исключительную сложность Git.	Понятные (похожие на команды Subversion)	Понятные
Число пользователей
	Большое / Много (и крупных) проектов на git	Большое / Много (и крупных) проектов на hg.	Меньше предыдущих: кроме проектов Canonical (Ubuntu, Launchpad), особо крутых проектов нет.
	Linux kernel, Cairo, Wine, X.Org, Rails, Rubinius, Compiz Fusion	Xine, OpenJDK, OpenSolaris, NetBeans, (Part of) Mozilla	Ubuntu (частично), Launchpad
Документация	Хороша. Хороший man с кучей примеров.	Хороша.	Хороша.
Платформы
	Плохая Windows-поддержка	Кроссплатформенный	Кроссплатформенный
Полезные особенности
	git скорее скриптуем, чем расширяем, что с одной стороны хорошо, а с другой — плохо. Легко использовать из скрипта, например, все тесты можно сделать из bash. Весьма настраиваем в продвинутом администрировании: Промежуточные области , Заброшенные объекты , detached heads, plumbing vs porcelain, reflogs . Возможны локальные (внутрирепозитарные) ветки.	Robust Renaming.	Robust Renaming. Поддержка легких checkouts (без истории). Bound branches. Возможны локальные (внутрирепозитарные) ветки. Patch Queue Manager (управление несколькими ветками, выполнение слияний для разработчиков)
Несколько крутых команд/расширений	git-stash (поддержка прерывания для краткого баг-фикса в другом проекте), git-cherry-pick (для выбора отдельных коммитов, без полных веток), git-rebase «Quilt-like changeset» типа Mercurial Queues). git add -i аналог Mercurial RecordExtension. Похоже тут есть все команды, которые вы бы могли захотеть.	RecordExtension — позволяет выбрать, какую часть изменений рабочего каталога вы собираетесь закоммитить. Hg Shelve Extension — аналог git-stash: — интерактивно выбрает изменения, чтобы их «обойти».	Shelf — аналог git-stash: поддержка прерывания для краткого баг-фикса в другом проекте, но похоже помирает — последнее изменение в марте 2007. bzr-dbus — для броадкаста ревизий и триггеров.
Проблемы
	Переименование не так хорошо, как в bzr . Настройка статического read-only HTTP-доступа слегка туповата (--bare и update-server-info). Обработка файлов в Unicode (UTF-16). Модель хранения. Git хранит каждый отдельный объект как отдельный файл, без обязательного вычисления дельты между ревизиями (это делает отдельная команда). Обязательно настройте, чтобы регулярно запускалась команда pack. Мешанина из C, Perl и скриптов на bash, что очень затрудняет полноценный перенос на другие системы.	Renaming not handled as good as bzr. [FIXED] Нет локальных веток, нужно использовать клон. Чтобы сэкономить место, Hg использует hardlinking, из-за чего возникают проблемы при pull (и еще под Windows). Расширение «Forest» (для подмодулей) неродное, и плохо документировано.
GUI
Windows	Уже не так все плохо	TortoiseHg	Сложновато. TortoiseBzr (нет коммитов после Aug 2007, хотя проект пока жив). WildcatBZR.
Linux	gitk, git-gui, tig, …	TortoiseHg, Hgtk, hgct	bzr-gtk, …
Инсталляция
	Нужен либо cygwin либо специальный git-дистрибутив типа Git on MSys
Бесплатные хостинги
	GitHub, gitorious	FreeHg	Launchpad

Полно еще споров, например, от том, что каталоги в Bzr это ветки, а не контейнеры веток, как в git.

А то, что Mercurial использует внешние инструменты для слияний, критикуют стороники Bazaar. Это исправлено с версии Mercurial v1.0.

Есть и другие нексколько предвзятые сравнения от Bazaar-команды:

• Bazaar vs Git,
• Bazaar vs Mercurial

и соответственно, ответ на это:

• reply from Mercurial.

Some User Statistics from Git Survey 2007

Обратите внимание, что в этом отчете не было возможности выбрать Ruby, неплохо было бы добавить его в опрос 2008 года.

Очень забавно, что треть людей используют DVCS взаимодействуюя с … 0 или 1 участниками!.

GUI

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

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

gitk on Linux

TortoiseHg on Windows

OliveGtk on Linux

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

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

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

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

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

Бенчмарки надо также гонять под Windows, ибо:

1. Даже если ваш сервер работает на *nix, многие разработчики по прежнему живут под Windows, и основная DVCS-работа идет именно у разработчиков под Windows.
2. Производительность под виндами точно должна отличаться.

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

Когда?

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

Kelly O’Hair

Мне удалось расспросить Kelly O’Hair из Sun на тему его выбора Hg для OpenJDK.

Я прочел причины перехода с TeamWare на Mercurial, но остались вопросы. Вы просто последовали за выбором проекта OpenSolaris?

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

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

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

Так ведь отчету для OpenSolaris, который был опубликован в апреле 2006, уже два года стукнуло…

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

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

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

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

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

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

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

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

И чем это лучше, чем TeamWare?

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

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

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

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

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

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

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

Pierre d’Herbemont

Также мне удалось расспросить на тему git и Pierre d’Herbemont из VLC.

Для начала, какую систему управления версиями вы использовали до git?

SVN, затем зеркало git-svn.

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

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

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

По пунктам:

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

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

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

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

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

Ну и что?

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

Subversion, один из лидеров CVCS не сдается и в производительности, и по функционалу и версия 1.5 уже должна быть неплохим компромиссом. Он может рассчитывать на существущих пользователей и дух простоты (за счет некоторых неудобств). В определенных случаях, как например в работе с большими бинарными файлами, Subversion должен быть лучше, чем DVCS так как пространство под рабочии копии остается неизменным. Также он эффективней, если вы активно используете частичные checkout-ы, (хотя если это происходит часто — это явная проблема недостаточного разбиения вашего проекта на модули).

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

И еще ранее не наблюдавшийся феномен — похоже, что многие делают выбор в зависимости от языка программирования сообщества:

• Java и разработка связанная с Sun более интересуется Mercurial
• C/Linux/Ruby/Rails -проекты сооблазняются git.

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

Благодарности

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

IRC-каналы #git, #mercurial, #bzr на Freenode IRC, #mozilla на Mozilla IRC. Картинка с бегунами от 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».

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 в 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 после коммантариев от Ian Clatworthy и портала reedit.

• Добавлены плагины Bzr и Windows GUI: rebase, …, Wildcat BZR, …
• Добавлен Hg Shelve.
• Обновлены SLOC для Hg (надо было еще учесть HTML-документацию, и оставил contrib, отвественный за поддержку Lisp и Tcl/Tk).
• Обновлен размер репозитория для git после правильной команды repack (git repack -a -f -d --window=100 --depth=100 после которой размер стал постоянным) (Спасибо за комментарий dhamma vicaya).

Извинения

darcs, Monotone! Простите, что не рассматривал вас в этом сравнении, так как мне и так пришлось неслабо поработать чтобы собрать всю эту информацию и протестировать эти три DVCS. Да, странно получилось, что хотя вы самые старые на DVCS-сцене, актуальны теперь в основном те DVCS, которых я рассматривал тут (конечно, вряд ли эта ситуация измениться, но добро пожаловать пользователям darcs и Monotone с комментариями и рекламой!).

Ссылки

• Очень исчерпывающие Wikipedia page about Git.

Distributed Revision Control Wikipedia page. Comparison of Revision Control Software Wikipedia page.

• Distributed Version Control — Why and How от Ian Clatworthy, Canonical (Bazaar).

• Intro to Distributed Version Control (Illustrated).

• Distributed Version Control Systems от Dave Dribin, который в конце концов выбрал выбрал Mercurial.

• Why Distributed Version Control.

• Source Code Management for OpenSolaris. OpenSolaris SCM Project History (2005).

• Mercurial OpenJDK Questions от Kelly O’Hair, Sun.
• Why I chose git.
• Distributed SCM от команды Gnome.
• FreeBSD SCM Requirements.
• Open Office Requirements.
• Mozilla VCS Requirements.
• Use Mercurial you git! от Ian Dees.
• What a DVCS gets you (maybe) от Bill de hÓra.
• The Differences Between Mercurial and Git.

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

Шпаргалки

• Git Cheat Sheet
• Mercurial Cheat Sheets
• Bazaar Quick Start Card

Условия тестов

Benchmark conditions

Тесты были проведены с использованием:

• AMD Athlon™ 64 Processor 3500+
• 1GB RAM
• Linux Kubuntu 6.10 Edgy x86_64 with ext3 fs.

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

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

• Mercurial 1.0 released от 2008-03-24 (c Issue 1050 patch опцией «Edgy inotify»)
• Git 1.5.5 от 2008-04-08
• Bazaar 1.3.1 от 2008-04-10

Репозиторий содержал слепок из 12456 changeset-ов (от 20080303, 70853 полных версий из hg-репозитория), ≈30000 файлов из репозитория Mozilla (изначально они были в hg-формате и сконвертированы в git-репозиторий с помощью hg-fast-export.sh, и в Bazaar-репозиторий с помощью hg-fast-export.sh плюс плагин fast-import). Для репозиториев использовались файловые форматы по умолчанию, и размер репозитория git оставался постоянными, при запуске git-gc (что в общем, считается нормальным для свежемигрировавшего репозитория). Правился один файл (dom/src/base/nsDOMClassInfo.cpp), точно как в тесте проводимом Jst полтора года назад.

Примечания

---

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