Различные распределенные системы контроля версий, работающие вместе

Question

В моем офисе установлена централизованная установка Source Safe 2005, которую мы используем для управления версиями.Я не могу изменить то, что офис использует на сервере.

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

Может ли какой-либо из существующих клиентов распределенного управления версиями справиться с этим?

Answer 1

Что ж...KernelTrap имеет что-то по этому поводу.Похоже, вы можете использовать vss2svn чтобы передать исходное безопасное репозиторий в репозиторий Subversion, затем используйте очень хороший git-svn для подключения к локальному репозиторию git.

Я бы предположил, что возврат коммитов в VSS не будет плавным, автоматическим процессом с использованием этого метода.

Answer 2

Вы должны иметь возможность ознакомиться с текущей версией кода, а затем создать вокруг нее репозиторий git.Обновление этого файла и передача его в ваш локальный репозиторий git должны быть безболезненными.Как и должно быть при его клонировании.

Единственная загвоздка в том, что вам нужно, чтобы они оба игнорировали друг друга (я сделал нечто подобное с SVN), изменив соответствующие файлы ignore.Я предполагаю, что SourceSafe позволит вам игнорировать происходящее.И вам нужно будет выполнить определенные операции дважды (например, сообщить обоим, что вы удаляете файл).

Answer 3

Это эпизод "HanselMinutes" охватывает именно то, что я надеялся услышать.По-видимому, Git можно использовать локально, а затем при необходимости подключать к внешним репозиториям subversion / vss.Они говорят об этом 14-15 минут подряд.

Answer 4

однажды я буду работать в компании, которая использует VSS (и в других компаниях, которые используют другие, менее неизвестные SCM) но я предпочитаю использовать SVN (когда-нибудь я попробую GIT) для активной разработки, для меня и моей группы.

Прежде всего, в этой ситуации это хорошая идея, только если коммитов в VSS немного в течение месяца, потому что работа с другими SCM (кроме VSS) дает вам больше гибкости, но переход на VSS из SVN требует больших затрат времени.

Моим решением было:

VSS -> SVN:У меня есть linux-скрипт (или ant-скрипт, или XXX-скрипт), который копирует текущую работу каталога обновлений VSS в текущий SVN, затем обновляет SVN-клиент и обновляет / объединяет / фиксирует в SVN.При этом вы обновляетесь в соответствии с изменениями остальной части компании, использующей VSS.

SVN -> VSS:Таким образом, вам нужно выполнить проверку всех ваших файлов modify в VSS, затем вы можете просто использовать обратный скрипт для копирования из каталога текущего обновления SVN (игнорировать каталоги .svn) и копирования в каталог текущего обновления VSS, обновления и фиксации.

Но помните, что в некоторых случаях это стоит того, чтобы потратить на это время.