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

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

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

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

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

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

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

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

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

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