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

голоса
14

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

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

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

Задан 04/08/2008 в 20:04
источник пользователем
На других языках...                            


4 ответов

голоса
1

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

Ответил 07/11/2008 в 17:51
источник пользователем

голоса
1

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

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

Ответил 04/08/2008 в 20:13
источник пользователем

голоса
1

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

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

Ответил 04/08/2008 в 20:10
источник пользователем

голоса
0

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

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

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

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

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

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

Ответил 18/08/2008 в 12:59
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more