Изменения

'''Mercurial''': отлично! Есть несколько расширений — [http://mercurial.selenic.com/wiki/HgSubversion hgsubversion], [http://pypi.python.org/pypi/hgsvn hgsvn], [http://mercurial.selenic.com/wiki/ConvertExtension convert], позволяющих работать с Subversion тем или иным образом, и не совместимых друг с другом. Самое вменяемое из них — '''hgsubversion''', хотя и заявлено, что оно ещё сырое, и, к сожалению, не распространяется вместе с Mercurial’ом. Имеет фактически весь необходимый функционал — можно делать и <tt>push</tt>, и <tt>pull</tt> в/из Subversion, можно клонировать SVN-репозиторий с сохранением веток и меток (правда, обязательно стандартное их расположение в корневых поддиректориях <tt>/trunk</tt>, <tt>/branches</tt>, <tt>/tags</tt>), эти два метода совместимы, <tt>rebase</tt> также работает, а граф ревизий ветвлений сохраняется.

Остальные два экстенжна «нинужны»: <tt>hgsvn</tt> — нечто более старое, работает сбоку от общего механизма, тоже позволяет делать push и pull, но не клонирует весь репозиторий, а только извлекает (checkout’ит) последнюю версию, чтобы далее можно было использовать Subversion и Mercurial вместе. Ну и конечно, оно не совместимо с <tt>hgsubversion</tt>. <tt>convert</tt> же предназначен для конвертации истории проекта из нескольких различных систем контроля версий в Mercurial, ни черта не совместим ни с <tt>hgsvn</tt>, ни с <tt>hgsubversion</tt> и не сохраняет граф ревизийветвлений. Зато, правда, поддерживает возможность переименования использования других имён поддиректорий <tt>trunk/branches/tags</tt>.

'''BazaarGit''': очень хорошо. Можно импортировать репозиторий командами (5-)! <tt>[http://git-svn.yhbt.net/ git-importsvn]</tt> или встроен в git и умеет всё, что нужно: клонирование, синхронизация (<tt>branchfetch</tt>, можно делать <tt>pushpull</tt> и или <tt>pullmerge</tt> ), фиксация изменений в/из Subversion. При импорте можно сохранить все ветки и метки в одном хранилище -репозиториях (если использовать shared repository<tt>dcommit</tt>)и <tt>rebase</tt> работают с сохранением веток и меток, для этого также требуются стандартные названия причём стандартная схема их именования <tt>trunk/branches/tags</tt>не является обязательной. Граф ревизий Subversion, увыВетки SVN импортируются как [http://www.gitready.com/beginner/2009/03/09/remote-tracking-branches.html Remote Tracking Branches], что тоже удобно — можно начинать историю ветки в git’е не сохраняетсяс сотворения миров, а с любого момента. Также существует несколько других расширений для импорта <tt>git-svn</tt> поддерживает подключаемые внешние репозитории Subversion в Bazaar(т. н. [http://svnbook.red-bean.com/en/1.0/ch07s03.html Externals]). Граф ветвлений, вроде-бы, сохраняется. На одном из SVN-репозиториев почему-то не сохранился. На тестах же всё получалось… Короче говоря, функционал полон, но все они ещё хужевозможно, есть баг.

'''Bazaar''': хорошо. Можно импортировать репозиторий командами <tt>svn-import</tt> или <tt>branch</tt>, можно делать <tt>push</tt> и <tt>pull</tt> в/из Subversion. При импорте можно сохранить все ветки и метки в одном хранилище (если использовать [http://bazaar-vcs.org/SharedRepositoryTutorial Shared Repository]), для этого также требуются стандартные названия <tt>trunk/branches/tags</tt>. Кроме того, я наткнулся на некоторые проблемы при фиксации изменений в Subversion после нескольких слияний двух Bazaar’овских веток, и пока не разрешил их. Граф ветвлений Subversion, увы, не сохраняется. Также существует несколько других расширений для импорта Subversion в Bazaar, но все они ещё хуже. Что ещё любопытно — с Subversion-репозиториями DVCS работают, как правило, гораздо быстрее самого Subversion, и быстрее всех работает '''Bazaar'''. То есть, в принципе, можно вообще жить с Subversion-сервером и Bazaar-клиентом.

Первое, что приходит на ум — это, конечно, аналоги [http://savannah.nongnu.org/projects/quilt quilt]'а, работающие поверх DVCS: [http://mercurial.selenic.com/wiki/MqExtension Mercurial Queues] (появился первым), [https://launchpad.net/bzr-loom Bazaar Loom], [http://www.procode.org/stgit/ StGIT]. Все они очень похожи и друг на друга, и на сам '''quilt'''. '''quilt''' вещь банальная, позволяющая автоматизировать тупое накатывание последовательности большого числа патчей и правку патча, который находится где-то в середине: можно откатить N верхних патчей, внести изменения в файлы и сказать refresh, и верхний на данный момент патч (то есть патч откуда-то из середины) обновится, дабы соответствовать внесённым изменениям. '''quilt''' создан на основе скриптов человека, который не использует системы контроля версий — Эндрю Мортона (Andrew Morton) — второго по значимости участника разработки ядра Linux после Линуса Торвальдса. Из реализаций quilt поверх DVCS появился именно MQ и долгое время, судя по всему, был «изюминкой» Mercurial’а, хотя на самом деле неидеален — идея добавления и удаления истории из/в репозиторий всё-таки странновата, а патчи не хранятся в том же репозитории, что и код — то есть, при клонировании исчезают. Крут ли quilt, нет ли — каждый решает сам для себя. Конечно, поддержке Debian-патчей на какой-нибудь Midnight Commander (их там в районе 60-и) quilt … помогает. Тем не менее, с моей точки зрения, некорректно закладываться на жёстко последовательное применение всех патчей. На самом деле, такие патчи логично организовывать в виде графа (графа зависимостей). Сразу будет видно, что большинство патчей независимы друг от друга, а зависимости окажутся на виду. Таким образом, задачу управления патчами удобнее всего решать, заводя по отдельной ветке на каждый патч. Причём даже есть расширения Mercurial [http://arrenbrecht.ch/mercurial/pbranch/ pbranch] (от patch branches) и Git [http://repo.or.cz/w/topgit.git TopGit] (от topic branches). Для Bazaar’а, увы, таких расширений нет. == Схема управления рабочими копиями == Что нам предлагают централизованные системы контроля версий? Некий «хардкод»: репозиторий ровно '''один''', рабочих копий много. Что нам предлагают DVCS? Теоретически, полный беспредел, то есть свободу. На практике — не совсем полную. '''Mercurial''' говорит нам: на ровно 1 рабочую копию ровно 1 репозиторий, и иначе быть не может. Это и удобно — сказал <tt>hg up ветка_такая_то</tt>, пара файлов поменялась, и опа — ты уже в другой ветке. Это и неудобно — чтобы положить на диск одновременно две разных ветки, нужно обязательно клонировать репозиторий (поддержки checkout нет). С '''Git''''ом ситуация почти такая же, как и с Mercurial’ом. 1 рабочая копия, 1 репозиторий. Хотя при клонировании данные репозитория можно и не копировать, задавая опцию <tt>--shared</tt>, но это скорее похоже на Bazaar’овские [http://doc.bazaar-vcs.org/latest/en/user-guide/stacked.html Stacked Branches], чем на Lightweight Checkout. Идея лёгких рабочих копий (или «идея .gitlink») [http://git.or.cz/gitwiki/SoC2007Ideas высказана для GSoC-2007], однако пока так и не реализована.

'''quiltBazaar''' — вещь банальнаявначале был хуже всех, позволяющая автоматизировать тупое накатывание последовательности большого числа патчей а потом стал лучше всех. Вначале он говорил нам: на 1 ветку ровно 1 рабочая копия и правку патчаровно 1 репозиторий. А когда исправился, который находится гдестало можно создать [http://bazaar-то в серединеvcs.org/SharedRepositoryTutorial Shared Repository] с опцией <tt>--no-trees</tt>, а потом сколько захочется рабочих копий <tt>checkout</tt>'ами. Переключить рабочую копию с ветки на ветку также можно — командами <tt>switch</tt> или <tt>qswitch</tt>.