Каковы препятствия и опасности при переходе с Visual SourceSafe на SVN?

Question

Клиент по-прежнему использует Visual SourceSafe, но, продемонстрировав многочисленные опасности и недостатки VSS, он решил перейти с VSS на SVN Subversion.

Будущим выбором кажется черепаха СВН с АнхСВН (хороший выбор?). Миграционная помощь описана здесь . Проект содержит два веб-сайта, несколько веб-приложений, несколько библиотек управления и функций.

Мне кажется, что "смести все связанные с VSS" , а затем "импорт в SVN" - это путь. Но миры не идеальны. Какие проблемы нам следует остерегаться, и какие меры мы можем предпринять, чтобы этот процесс прошел гладко? Существуют ли типичные проблемы SVN для .NET, о которых нам следует знать?

РЕДАКТИРОВАТЬ: Можно ли как-то перенести историю VSS тоже, или мы должны считать это только новым началом?

Answer 1

Есть несколько инструментов, которые могут перенести историю для вас. Мы использовали VSS2SVN несколько лет назад, чтобы сделать этот же шаг.

Вы можете использовать несколько клиентов Subversion бок о бок. Почти каждый пользователь Windows Subversion, которого я знаю, использует TortoiseSVN, и для интеграции в Visual Studio вы можете использовать AnkhSVN (бесплатный, полный поставщик SCC для VS 2005+ начиная с AnkhSVN 2.0) и VisualSVN (коммерческий; использует TortoiseSVN со своими собственными расширениями и предоставляет SCC-подобный функции в VS 2003 +).

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

См. AnkhSVN против VisualSVN для дополнительных сравнений между VisualSVN и AnkhSVN. Но обратите внимание, что все клиенты (TortoiseSVN, AnkhSVN, VisualSVN) являются просто оболочкой для одних и тех же библиотек, поэтому вы можете переключаться между ними в любое время.

Answer 2

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

Основные проблемы, с которыми мы столкнулись, были связаны с природой самого Subversion, а не с миграцией. Проблемы, с которыми мы столкнулись, были:

1. Обучение работе со слиянием, а не эксклюзивными проверками.
2. Узнав, что ничего не удаляется в Subversion. Таким образом, добавление вашего установщика с предварительными требованиями и последующее удаление не уменьшит размер хранилища. Наш текущий размер резервной копии - 4 ГБ + сжатый.
3. Для резервного копирования требуется немного сценариев, в отличие от SourceSafe, который был простой копией файла. svnadmin hotcopy работал для нас.
4. Мы обнаружили, что «ветви пользователя», где у каждого пользователя есть отдельная ветка, у нас не работают. Теперь у нас есть одна магистраль для всех пользователей.
5. Удалось зафиксировать изменение без комментариев. Вы можете исправить это с помощью ловушки перед фиксацией.
6. Отказ от интеграции с MS Visual Studio. Не так плохо, как кажется.

Answer 3

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

Оформить заказ Изменить регистрацию, чтобы изменить фиксацию объединения:

Разработчики, плохо знакомые с SVN, должны быть согласны с идеей двух разработчиков, вносящих изменения в файл одновременно, и что они объединят эти изменения позже. Пользователи VSS, как правило, не знают, что такой стиль управления исходными кодами даже возможен, и наверняка не чувствуют себя комфортно при переходе.

Привязка проекта к привязке файловой системы:

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

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

Ветвление:

Хотя вы можете выполнять ветвление в VSS, я редко видел, чтобы кто-нибудь использовал его, потому что довольно сложно настроить ветку, переключиться на ветку и затем объединить ветку, когда вы закончите с ней. Для использования SVN ветвления не требуется, но, вероятно, это одна из главных причин, по которой вы должны перейти. Разработчики должны освоиться с идеей создания веток там, где это кажется уместным, и повторного объединения их в магистраль.

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

Answer 4

Номер один совет: храните резервную копию :) Номер два: Turtoise SVN - ознакомление с возможностями Windows-машины, а также интеграция с Visual Studio (через VisualSVN)