Лучший способ перейти с VSS на Subversion?

Question

Я один разработчик, который хочет выйти из Visual Source Safe и перейти на SVN.

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

Кто-нибудь сделал это успешно, и может порекомендовать метод?

Answer 1

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

Если вам нужно вести историю, сделайте свой VSS-репозиторий доступным только для чтения.

Answer 2

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

http://vss2svn.codeplex.com/

Answer 3

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

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

Чуть подробнее здесь .

Answer 4

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

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

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

Эрик.

Answer 5

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

Answer 6

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

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

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

Answer 7

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

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

Answer 8

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

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

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

Answer 9

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

Answer 10

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

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