Изменения

Что ещё любопытно — с Subversion-репозиториями DVCS работают, как правило, быстрее самого Subversion, и быстрее всех работает '''Bazaar'''. То есть, в принципе, можно вообще жить с Subversion-сервером и DVCS-клиентом (если, конечно мириться с постоянными слияниями и rebase’ами).

'''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>trunk</tt>'а, то есть, копированием некоторых его поддиректорий, успешно подцепилась в нужное место графа ветвлений. Ни Bazaar, ни Git этого не смогли.

Остальные два экстенжна «нинужны»: <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>.

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

'''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 сохраняется, но также не отражает копирования подпапок. Также существует несколько других расширений для импорта Subversion в Bazaar, но они хуже.

== Управление патчами ==

Первое, что приходит на ум — это, конечно, аналоги [http://savannah.nongnu.org/projects/quilt quilt]'а, работающие поверх DVCS: [http://mercurial.selenic.com/wiki/MqExtension Mercurial Queues] (MQ), [https://launchpad.net/bzr-loom Bazaar Loom], [http://www.procode.org/stgit/ StGIT]. Все они очень похожи и друг на друга, и на сам '''quilt'''. MQ и StGIT достаточно развиты и стабильны. bzr-loom же пока находится на стадии развития.

'''quilt''' — вещь банальная, позволяющая автоматизировать тупое накатывание последовательности большого числа патчей и правку патча, который находится где-то в середине: можно откатить N верхних патчей, внести изменения в файлы и сказать <tt>refresh</tt>, и верхний на данный момент патч (то есть патч откуда-то из середины) обновится, дабы соответствовать внесённым изменениям. '''quilt''' создан на основе скриптов человека, который не использует системы контроля версий — Эндрю Мортона (Andrew Morton) — второго по значимости участника разработки ядра Linux после Линуса Торвальдса.

'''Mercurial''''овский '''pbranch''': хорошо. Умеет весьма немногое. Самые полезные команды — это <tt>pdiff</tt>, <tt>pgraph</tt> и <tt>pmerge</tt>. <tt>pdiff</tt> экспортирует текущий патч '''без его родителей''' в стандартном формате. <tt>pgraph</tt> показывает граф зависимостей патчей, из которого можно, по сути, понять, в какой последовательности их накатывать, если они сами уже экспортированы. Ну и просто вообще граф патчей — это удобно. <tt>pmerge</tt> объединяет изменения, произошедшие в зависимостях патча, в патч.

Хотя и то, и другое, в принципе, сделать можно и так. Плюс же расширения заключается в [http://arrenbrecht.ch/mercurial/pbranch/index.htm хорошей online-документации] — у TopGit такой нет…

'''TopGit''': тоже весьма хорошо, даже чуть получше (версия на момент тестирования была 0.8). А в будущем станет ещё лучше — по ходу просмотра справки по некоторым командам выводится по одному-два TODO — значит, они, наверное, появятся. Забавная, кстати, вещь. Явно написана в общем духе git-а (смесь скриптов на bash, perl и программ на C). «Головной» скрипт '''<tt>tg</tt>''' (TopGit) написан на шелле, и команды <tt>tg --help, tg -h, tg help</tt> и т. п. сначала вводят в недоумение — «<tt>no git repository here</tt>». Справку TopGit печатать умеет, но для этого сначала надо зайти в git-репозиторий :) типа ''Чего ты спрашиваешь? У тебя интерес реальный? Ты покупать будешь или нет?..''

;delete: удалить ветку-патч.

;depend: редактировать зависимости.

;import: импортировать коммиты в виде патчей.

;info: аналог <tt>hg pstatus</tt>, выводит состояние ветки — сколько, чего и откуда надо обновить и т. п.