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

Question

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

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

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

Answer 1

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

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

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

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