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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 5

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

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

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