Кто-нибудь успешно перенес VSS 2005 в SVN?

Question

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

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

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

Кто-нибудь успешно перенес свой источник из VSS 2005 в SVN, и если да, то какие инструменты вы использовали и каковы были ваши выводы? Любые предостережения или ошибки были бы наиболее полезными, так что знайте, а также все, что было полезным / удивительным или было разочарованным или просто искаженным.

Answer 1

Попробуйте последнюю версию транка (консольного приложения) для VssMigrate на Codeplex, чтобы изменить порядок вашей истории и заново сгенерировать наборы изменений из вашего хранилища VSS. Он также будет правильно упорядочивать ваши ревизии в зависимости от времени их регистрации.

http vssmigrate.codeplex.com/SourceControl/changeset/view/16890

Надеюсь, это поможет. Может потребоваться некоторая настройка $ / import.

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

P.P.S. Вы даже можете использовать новую версию VssMigrate, чтобы повторно импортировать ревизии в хранилище subversion, а затем объединить все ревизии после последней редакции импорта из вашей предыдущей ревизии. Единственным недостатком является то, что каждый должен будет получить новую проверку из хранилища, потому что количество ревизий будет значительно сокращено. В основном, совершите новую миграцию; svnadmin dump активный ранее перенесенный репозиторий из rev перенесенный +1 как инкрементный, а затем загрузка svnadmin в недавно перенесенный репозиторий.

Answer 2

Я пробовал и Polarion, и vss2svn около года назад.

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

За последний год было несколько раз, когда я искал старую историю, но на самом деле не так уж много. Еще одним плюсом для начала является то, что ваш новый SVN-репозиторий будет очень быстрым!

Answer 3

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

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

Answer 4

Я успешно перенес VSS 2005 в SVN несколько месяцев назад. Я использовал инструмент «VssMigrate.Tim2», который, по-видимому, теперь используется в CodePlex как vssmigrate . Это работало нормально без каких-либо серьезных проблем. Казалось, что редакции и временные метки были заказаны не совсем так, как я ожидал, но это не имело большого значения.

РЕДАКТИРОВАТЬ: С vssmigrate вы можете выбрать миграцию определенного пути VSS (например, $ / GroupA / ProjectB), который сокращает время для отдельной миграции и делает весь процесс менее хрупким. Я не нашел этот процесс слишком долгим, хотя у нас было только около шести месяцев данных в VSS. Мне удалось завершить миграцию и настройку Apache + SVN за выходные. В зависимости от размера вашего VSS-репозитория вы можете захотеть создать несколько SVN-репозиториев вместо огромного одного репозитория.

Я очень рад, что мы отошли от VSS, хотя настройка Apache + SVN была не слишком веселой (методом проб и ошибок). Я рассматривал Git или Mercurial , но в то время не было ни надежного инструмента TortoiseXxx, ни плагина VS SCC. Хотя теперь, когда Google code поддерживает Mercurial и TortoiseHg выглядит хорошо, я очень скоро собираюсь попробовать Mercurial.

Answer 5

Аналогично этому вопросу - другая миграция, но я также думаю, что попытка захвата истории - это пустая трата усилий / времени.

Как лучше всего перейти с SourceSafe на ClearCase?