Лучший способ мигрировать от VSS до Подрывной деятельности?

Версия VSStoSVN для CodePlex - одна из лучших, которые я нашел. У меня были довольно плохие результаты с версией PumaCode, но она прошла гладко.

http://vss2svn.codeplex.com/

Мы недавно сделали эту миграцию на работе. Я настоятельно рекомендую:

1. Просто добавляют новый код от VSS, получают удар, что pre-svn история должна будет остаться в старом репозитории VSS.
2. , Если Ваш репозиторий VSS все еще используется после начального дампа кода, переместите изменения с помощью Ответвления Поставщика . Т.е., предположите, что Ваш репозиторий VSS является поставщиком, и используйте датированные теги для слияния изменений в репозиторий SVN.

Немного больше детали здесь .

Моя компания разработала инструмент миграции Source Safe на Subversion: http://www.abstrakti.com/en-US/Products/Krepost

Этот инструмент был разработан после проблемы с любым другим инструментом, когда нам пришлось перенести репозиторий клиента.

Дайте мне знать, если у вас возникнут проблемы, я буду рад вам помочь.

Эрик.

Следующий инструмент работает довольно хорошо: http://www.pumacode.org/projects/vss2svn/wiki/RunningTheMigration

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

Редактировать: домен pumacode.org исчез, код размещен на https://github.com/irontoby/vss2svn

В моем текущем задании мы просто создали репозиторий подрывной деятельности, сценарии рычага установки для игнорирования всего vss и сгенерированных файлов, и затем только что начали импортировать различные проекты с tortoiseSVN. Разработанный довольно достойный, мы были в порядке в течение нескольких часов.

Я полностью согласен с ответом Джона Галлоуэя. Я также попытался использовать vss2svn , но обнаружил, что с импортированным репозиторием было много проблем, и в итоге решил, что оно не стоит усилий, необходимых для его очистки. Мы просто импортировали копию кода в Subversion и вернулись в VSS в том редком случае, когда нужно было обратиться к более старой версии кода.

В моей предыдущей компании мы также использовали тот же подход для перехода с ClearCase на Subversion, и я не могу вспомнить ни одного случая, когда нам когда-либо приходилось возвращаться в ClearCase, чтобы взглянуть на историю.

Самая большая проблема заключалась в том, чтобы заставить всех переключиться на новый репозиторий одновременно, но как один разработчик, у вас не должно быть никаких проблем!

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

Также по политическим причинам я написал несколько действительно хакерских сценариев, в которых VSS обновлялся с изменениями из Subversion. Они работали некоторое время, но продолжали ломаться каждую неделю или две, пока кто-то не переименовал каталог или что-то в этом роде, и все это рухнуло. К тому времени было нормально просто продолжать использовать Subversion.

Мы загрузили и протестировали несколько инструментов миграции, и я бы порекомендовал Polarion SVNImporter .

Мы использовали его для выборочной миграции почти на Гб из репозитория VSS6 в Subversion. Поскольку исходный код доступен, мы смогли исправить его и адаптировать к нашим конкретным потребностям (обнаружение связанных файлов).

Я использовал vss2svn с большим успехом.