Я один разработчик, который хочет выйти из Visual Source Safe и перейти на svn.
Быстрый поиск создает несколько инструментов, но я не вижу явного победителя, и я не могу позволить себе тратить много времени на тестирование различных инструментов.
Кто-нибудь сделал это успешно и может рекомендовать метод?
Я рекомендую просто добавить ваш код в новый репозиторий Subversion, а не импортировать из VSS. VSS имеет свернутую модель управления версиями, которая не хорошо переводится во многие другие системы, и просто начинать свежие - это, как правило, лучший способ избежать этого беспорядка с вами.
Если вам нужно сохранить историю, сделайте свой репозиторий VSS доступным только для чтения.
Версия CodePlex VSStoSVN является одним из лучших, которые я нашел. У меня были неплохие результаты с версией PumaCode, но эта работа прошла гладко.
Недавно мы работали над этой миграцией. Я настоятельно рекомендую:
Немного подробнее здесь.
Моя компания разработала инструмент миграции "Исходный безопасный для Subversion": http://www.abstrakti.com/en-US/Products/Krepost
Этот инструмент был разработан после проблем с любым другим инструментом, когда нам пришлось перенести репозиторий клиентов.
Сообщите мне, если у вас возникнут проблемы, я буду рад помочь вам.
Эрик.
Следующий инструмент работает достаточно хорошо: http://www.pumacode.org/projects/vss2svn/wiki/RunningTheMigration
Для очистки импортированного репозитория требуется небольшая работа, но если вы действительно хотите сохранить свою историю, это может стоить того.
Изменить: домен pumacode.org отсутствует, код теперь размещен на https://github.com/irontoby/vss2svn
Я использовал vss2svn с большим успехом.
В моем текущем задании мы просто создали репозиторий subversion, установили скрипты hook, чтобы игнорировать все vss и сгенерированные файлы, а затем только начали импортировать различные проекты с tortoiseSVN. Проработав довольно прилично, мы работали в течение нескольких часов.
Я полностью согласен с ответом Джона Галлоуэя. Я также попытался использовать vss2svn, но обнаружил, что с импортированным репозиторием возникло множество проблем, и в конце концов решил, что это не стоит усилий, необходимых для его очистки. Мы просто импортировали копию кода в подрывную деятельность и вернулись в VSS в редкий случай, когда нужно проконсультироваться с более старой версией кода.
В моей предыдущей компании мы также использовали один и тот же подход для перехода от ClearCase к Subversion, и я не помню случая, который нам когда-либо понадобился, чтобы вернуться в ClearCase, чтобы посмотреть на историю.
Самая большая проблема заключалась в том, чтобы заставить всех переключиться на новый репозиторий одновременно, но в качестве одного разработчика у вас не должно быть никаких проблем!
Мы загрузили и протестировали несколько инструментов миграции, и я бы порекомендовал Polarion SVNImporter.
Мы использовали его для проведения выборочной миграции почти Gb из репозитория VSS6 в Subversion. Поскольку исходный код доступен, мы смогли его исправить и адаптировать к нашим конкретным потребностям (обнаружение связанных файлов).
Я использовал некоторый script (я не помню, какой), чтобы помочь в преобразовании VSS в SVN. Это было немного больно и лаконично, но закончилось тем, что работало и сохраняло всю историю. В то время мне приходилось вести всю историю по политическим причинам; если бы у меня был свой путь, я, вероятно, выбросил бы историю и импортировал весь код в SVN.
Также по политическим причинам я написал несколько действительно взломанных скриптов, которые обновили VSS с изменениями в Subversion. Они работали некоторое время, но продолжали ломаться каждую неделю или две, пока кто-то не переименовал каталог или что-то еще, и все это развалилось. К тому времени было нормально продолжать использовать Subversion.