Мой офис имеет центральную установку Source Safe 2005, которую мы используем для управления версиями. Я не могу изменить то, что использует офис на сервере.
Я развиваюсь на ноутбуке и хочу иметь другой локальный репозиторий управления версиями, который может синхронизироваться с центральным сервером (когда он доступен) независимо от того, что этот центральный поставщик. Причина запроса заключается в том, что я могу поддерживать локальную стабильную ветку/сборку для презентаций клиентов, продолжая развиваться без необходимости перепрыгивать через пылающие обручи. Кроме того, в качестве консультанта мои клиенты могут потребовать, чтобы я использовал их поставщика контроля источника, и гибкость здесь облегчит жизнь.
Может ли какой-либо из существующих клиентов управления распределенным источником обрабатывать это?
Ну... KernelTrap имеет что-то в этом. Похоже, вы можете использовать vss2svn, чтобы передать репозиторий Source Safe в репозиторий Subversion, затем используйте очень приятный git -svn для вытащите локальный репозиторий git.
Я бы предположил, что коммиты назад к VSS не будут плавным, автоматическим процессом, используя этот метод.
Вы должны иметь возможность проверить текущую версию кода, а затем создать репозиторий git. Обновление этого параметра и его фиксация в локальном хранилище git должно быть безболезненным. Как и клонирование.
Единственное, что вы должны сделать, чтобы они оба игнорировали друг друга (я сделал что-то подобное с SVN), возившись с соответствующими файлами игнорирования. Я предполагаю, что SourceSafe позволяет игнорировать вещи. И вам нужно будет выполнить определенные операции дважды (например, сказать, что вы удаляете файл).
Этот эпизод HanselMinutes охватывает именно то, что я надеялся услышать. По-видимому, Git может быть использован локально, а затем привязан к внешним хранилищам subversion/vss по мере необходимости. Они говорят об этом 14-15 минут.
когда-нибудь я работаю в компании, использующей 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-каталога, обновление и фиксация.
Но помните, что в нескольких случаях стоит того, чтобы сделать это.