Мы сделали то же самое несколько лет назад (от VSS до SVN).
Прежде всего, расскажите вашим разработчикам о философии SVN и VSS.
- В VSS мы «зарезервировали» файлы (это означает, что другие разработчики больше не могли зарезервировать файл), затем внесли изменения и снова зафиксировали файлы.Это принцип блокировки-редактирования-разблокировки.
- SVN использует принцип fetch-edit-merge-commit.Ваши разработчики могут испытывать смешанные чувства по этому поводу, так как они больше не уверены, что смогут редактировать файл только один раз.Убедить их.Наша команда разработчиков выросла до 15 разработчиков, и до сих пор мы никогда не сталкивались с конфликтами, которые оставались бы незамеченными.
Во-вторых, рассмотрим перенос минимальной истории из VSS в SVN.Возможно, было бы излишним копировать каждую маленькую деталь истории из VSS в SVN, но все же имеет смысл копировать, например, каждую версию за последние 5 лет вашего приложения в SVN.
В-третьих, исследуйте особенности SVN, которыене существует в VSS.Некоторые из них могут открыть новые возможности в вашей организации.Очень хорошим является концепция «пересмотра».VSS не имеет глобального номера ревизии, что означает, что трудно сослаться на конкретную ситуацию (если вы не начнете маркировать все).В SVN ревизии позволяют ссылаться на любой момент в истории хранилища SVN.Вы можете использовать номер ревизии, например, в процессе сборки (например, версия 1.0 вашего приложения может быть ревизией 12345, вы можете интегрировать номер ревизии в вашу систему отслеживания ошибок ...).
В-четвертых, используйте дополнительные инструментынапример, TortoiseSVN (расширение оболочки) и VisualSVN (дополнение к Visual Studio).