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

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

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

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

4.08.2008 19:04:47
4 ОТВЕТА
РЕШЕНИЕ

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

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

1
4.08.2008 19:13:23

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

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

1
4.08.2008 19:10:29

однажды я работаю в компании, которая использует 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, обновить и зафиксировать.

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

0
18.08.2008 11:59:44

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

0
7.11.2008 16:51:43