Как сделать DVCS полностью совместимым с Subversion?

Question

Какие архитектурные изменения потребуются для полной совместимости DVCS с Subversion?

Многие DVCS имеют двунаправленный интерфейс с Subversion, но есть ограничения и предостережения. Например, git-svn может создать репозиторий, который отражает Subversion, и изменения в этом репо могут быть отправлены обратно в Subversion через 'dcommit'. Но man-страница git-svn явно предостерегает от создания клонов этого репозитория, так что по сути это рабочая копия Subversion, с которой вы можете использовать команды git. Bazaar также имеет возможность двунаправленной Subversion, но в документации отмечается, что свойства Subversion вообще не поддерживаются.

Вот конец, который я преследую. Мне нужен репозиторий Subversion и репозиторий DVCS, которые в устойчивом состоянии имеют идентичный контент. Когда что-то меняется на одном, оно автоматически отражается на другом. Пользователи Subversion нормально взаимодействуют с хранилищем Subversion. Пользователи DVCS клонируют репозиторий DVCS, извлекают из него изменения и возвращают изменения в него. Самое главное, им не нужно знать, что этот специальный репозиторий DVCS связан с репозиторием Subversion.

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

Я думаю, что в основном нужно улучшить двунаправленную способность, чтобы изменения свойств Subversion транслировались в изменения в репозитории DVCS. Некоторые изменения в хранилище DVCS будут преобразованы в изменения свойств Subversion.

Или это ответ на создание новой возможности в Subversion, которая взаимодействует с репозиторием DVCS, используя репозиторий DVCS в качестве просто специального уровня хранения, такого как fsfs или bdb?

Если не существует прямого сопоставления между вещами, которые Subversion и DVCS считают имеющими версии, означает ли это, что всегда будет какое-то действие, которое не может быть записано должным образом на одном или другом?

Answer 1

Мой вывод после размышлений об ответах, которые я получил, а также о некоторых беседах с другими, заключается в том, что обязательно нужно было бы сопоставление «один к одному» между вещами, которыми может управлять Subversion и DVCS. Если нет, то истинная совместимость не может существовать.

Я не думаю, что существуют какие-либо DVCS, которые даже являются кандидатами на это. Как указывает Крис Камински, возможно, Subversion решит проблему в будущем, включив распределенные возможности.

Я задал вопрос, потому что я работаю в организации, где мы приближаемся к концу долгой и мучительной миграции с CVS на Subversion. Subversion очень хорошо отвечает потребностям организации - имея централизованный источник правды. Среди программистов есть крошечные, но растущие чувства, что они хотят использовать git или другие модные системы DVCS. Поскольку git-svn в основном просто модный клиент Subversion, есть несколько довольная среда. OTOH, имея централизованное хранилище, может вызвать раздражение, например, кто-то работает в Индии с задержкой в ​​сотни миллисекунд на сервер. Кроме того, это всего лишь вопрос времени, когда все наши новые сотрудники обнаружат, что они никогда не использовали ничего, кроме git / hg / bzr / что угодно. Я думаю, что они будут жить в мире централизованного хранилища Subversion.

Итак, мне было интересно, существует ли способ сделать это обоими способами: хранилище Subversion, которое хочет организация, и вокруг которого строятся многие другие процессы, и новые блестящие инструменты DVCS, которые требуются хипстерским программистам!

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

Answer 2

Я не думаю, что есть действительно родной способ сделать оба инструмента полностью функциональными, особенно если учесть, что:

• SVN - это контроль версий, который эмулирует теги и ветки с каталогами
• SVN не записывает информацию о слиянии, как Git

(см. SVN против Git )

Так хочется, чтобы «пользователям на стороне DVCS не нужно было знать, что хранилище Subversion даже существует». немного надуман, по крайней мере без промежуточного мерзавца, как Крис предлагает в своем ответе .

Я бы просто добавил, чтобы оценить svn2git и git2svn , чтобы ваши "пользователи на стороне DVCS" имели дело с git repo не отражает "каталоги", которые на самом деле должны были быть ветвями.
(см. « Клонирование нестандартного Svn-репозитория с помощью Git-Svn »)

Answer 3

Это называется git, и с помощью git-svn вы можете взаимодействовать с клиентами Subversion. Предостережение относительно git-svn - это не git <-> svn, это (git <-> git) <-> svn. По сути, они говорят, что если вы используете git для доступа к SVN-репозиторию, НЕ делитесь своим git-репозиторием с кем-либо еще через push / pull. В противном случае это работает просто отлично. В основном вы получаете отключенный контроль исходного кода сетевого хранилища Subversion. Это все.

Если вы хотите что-то более «чистое», есть SVK, который представляет собой DVCS, построенный поверх Subversion, но авторы его больше не выпускают (хотя он и с открытым исходным кодом - PERL).

У ребят из Subversion есть некоторые возможности DVCS на дорожной карте, вероятно, благодаря успеху SVK и растущей распространенности git / mercurial / bazaar.