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

Question

Я относительно новичок в управлении версиями, и пока у меня есть опыт работы с Subversion с использованием TortoiseSVN/VisualSVN. Я читал о других типах VCS (git, mercurial и т. Д.), И я рассматриваю их, но многие аргументы за или против конкретного VCS кажутся, что они в значительной степени сводятся к субъективным предпочтениям, Вероятно, все закончится, и каждый посмотрит.

Задумываясь об этом, мне было интересно, можно ли даже теоретически использовать несколько VCS на одной кодовой базе. Какая (если таковая имеется) комбинация VCS может быть такой возможностью? И если это возможно, сколько из логистического кошмара будет пытаться манипулировать соответствующими списками исключений?

Одним из возможных аргументов для этого может быть резервное резервирование. Несколько провайдеров VCS (Beanstalk, Github, Bitbucket) предлагают один бесплатный репозиторий, поэтому вы можете иметь одно и то же резервное копирование в разных местах.

Answer 1

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

git-svn. Теперь разработчики нажимают и вытаскивают их из собственных локальных репозиториев Git в центральный репозиторий Subversion, но все же получают всю крутую мощь Git. Этот процесс полностью и полностью прозрачен для репозитория Subversion, который просто видит изменения, которые ему нажимают.

Answer 2

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Если вы используете базар для своего локального репозитория, the most problematic thing - это когда ваш локальный репозиторий базара расходится и вы хотите зафиксировать свой удаленный репозиторий. Иногда вам нужно выполнить «push overrite», чтобы решить эту проблему.

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

Answer 6

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

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

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

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

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