Несколько одновременных систем управления версиями?

Обычно сложно (но не невозможно) обрабатывать несколько VCS на одной кодовой базе. Однако вы потенциально можете столкнуться с проблемами при удалении файлов ... Иногда один виртуальный канал не понимает, что файл был удален.

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

Моим первым ответом, когда я прочитал ваш вопрос, было: «Конечно, технически возможно, но действительно очень плохая идея».

Я немного отступлю после просмотра других комментариев. Хорошо, у каждого пользователя может быть локальный репозиторий, отдельный от центрального репозитория, и он может использоваться для сохранения контрольных точек во время работы. В этом случае они могут быть полностью отдельными VCS, и это не имеет значения.

Но если вы думаете о двух разных VCS, одновременно удерживающих ваш центральный репозиторий, это технически возможно, но действительно очень плохая идея. Весь смысл VCS заключается в том, что вы ведете историю всех изменений, внесенных в файлы, чтобы вы могли видеть, какие изменения были внесены, когда и - если пользователи включают в себя приличные комментарии к коммитам - почему. Если клиент, у которого есть 19 июня, Версия 2007 имеет проблему, вы можете получить код точно так же, как он существовал 19 июня 2007 года, поэтому вы отлаживаете код, который фактически запускает пользователь. Если вы обнаружите, что последнее изменение было большой ошибкой, вы можете откатиться. И т. Д. И т. Д.

Но если у вас два репозитория ... Собираетесь ли вы делать все коммиты одинаково для обоих репозиториев? По крайней мере, это куча дополнительной работы. В худшем случае, рано или поздно кто-то совершит ошибку, забудет зафиксировать одну или не зафиксирует до следующего дня после того, как кто-то другой сделал промежуточную фиксацию, и репозитории на самом деле не будут идентичными. Или вы собираетесь чередовать, иногда выезжая из А, а иногда из Б? Но тогда никто никогда не узнает, что в них.

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

Я знаю, что здесь не совсем используются несколько VCS, но некоторые VCS могут иметь разные внешние интерфейсы. Git, например, может иметь внешний интерфейс SVN, чтобы клиенты SVN могли использовать репозиторий Git (и они не будут знать, что это Git). Думаю, для него есть и другие внешние интерфейсы.

Конечно, это возможно. Я использую git-svn для обновления моего локального репозитория git и фиксации в корпоративном репозитории svn. С любым инструментом VCS, который вы решите использовать, проблема, с которой вы, скорее всего, столкнетесь, будет во время обновления вашего локального репозитория с изменениями из удаленного репозитория.

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

Я не испытываю этой «проблемы с разделенным репозиторием» при использовании git-svn для обновления моего локального репозитория git с изменениями из удаленного репозитория svn. Но иногда, когда я делаю "git svn rebase" у него будут конфликты, и если вы не выполните процедуру, чтобы разрешить его правильно, вы можете потратить много времени. Поскольку я сталкивался с этим снова и снова, я задокументировал это , и сейчас я не считаю это таким уж большим делом.

Mercurial (с hgsubversion), git (с git-svn) и bzr (bzr-svn) имеют опцию для синхронизации с вышестоящим репозиторием svn.

Так что уже возможно (при условии, что расширения работают достаточно хорошо) взаимодействовать с репозиторием svn с разными SCM.