Visual Source Safe -- > TFS Миграция

Существует несколько различных способов миграции. Инструмент будет тянуть вашу историю и т.д. но более прагматичный и простой способ-это заблокировать VSS как архив истории и начать все заново:

1. Пусть все проверят все изменения в VSS, убедитесь, что все строится и т. д.
2. Установите для всех баз данных VSS значение "locked" (права только на чтение для всех пользователей)
3. Получить последние данные по всей базе данных VSS в набор папок "clean" на рабочей станции
4. Проверьте все файлы в TFS с рабочей станции

Для любой истории, предшествующей преобразованию, людям нужно перейти к VSS, но через неделю или две это вряд ли произойдет так часто. И вы знаете, что история в VSS точна и не искажена процессом преобразования.

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

Если вы все же решите использовать средство VSSConverter.exe, поставляемое с Visual Studio Team Foundation Server, то сначала следует установить TFS 2008 SP1 , поскольку оно включает ряд улучшений, описанных в этом блоге командой средств миграции .

Некоторые из ключевых особенностей релиз включает в себя:

Устранение конфликтов пространств имен . Я ранее в блоге об этом писали как "the rename problem" и мы исправили конвертер для корректной миграции файлов с перекрывающимися пространствами имен. Это было так самая большая болевая точка для большинства пользователей попытка использовать предыдущие версии программы инструмент.

Автоматическая повторная привязка решения. В этой последней версии, VS решение файлы будут автоматически обновлены до версии 9.0 и вернулся в систему к управлению версиями. Ранее пользователи требовалось сделать это вручную.

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

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

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

Однако я хотел бы порекомендовать вам одну вещь: резервное копирование. Сделайте резервную копию всего, прежде чем сделать это. Если что-то пойдет не так, лучше перестраховаться, чем потом сожалеть.

Мои ссылки не появляются. Это адрес: http://msdn.microsoft.com/en-us/library/ms181247(VS.80).aspx

В настоящее время мы занимаемся этим на моей повседневной работе. На самом деле мы переходим примерно через месяц. Я-основная часть миграции и большая часть того, почему мы выходим из SourceSafe. Чтобы помочь в переносе, я использовал образ Visual Studio ® Team System 2008 Team Foundation Server и Team Suite VPC . Это было очень полезно. Сразу же, образ содержит полную рабочую установку TFS для вас, чтобы играть и демо-версию. Он также включает в себя практические лаборатории, и одна из лабораторий работает с инструментом миграции VSS -> TFS. Если у вас есть подписка MSDN, после того как вы сыграли с образом, следующим шагом будет установка TFS Small Team edition, которая поставляется вместе с вашей подпиской.

Обратите внимание на то, что в образе должны быть установлены последние пакеты обновления для Visual Studio 2008 и платформы .NET. Пакеты обновления исправили некоторые досадные ошибки, и это определенно повысило удобство использования системы. У нас есть довольно большая база данных SourceSafe с более чем 90 проектами, и инструмент миграции занял около 32 часов. Сначала я сделал резервную копию нашей базы данных sourcesafe для тестирования. Затем я сделал миграцию на базе данных test sourcesafe. После этого я проверил исходное дерево в TFS, и все прошло нормально. Мы сохранили всю историю для наших исходных файлов с VSS, что было здорово. Нет необходимости держать эту вонючую базу данных VSS вокруг после того, как мы выйдем в эфир.

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

Мой совет - сделать миграцию поэтапно. Не делайте слишком много за один раз. Дайте время людям, которые будут использовать систему для обучения.

VSS конвертер-это далеко не идеальное решение. И есть существенные различия между версией конвертера 2005 и 2008SP1.

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

Кроме того, VSS Converter 2008 требует, чтобы эти учетные записи домена были действительными TFS учетными записями. В то время как конвертер 2005 года не обеспечивает этого.

Если ваша история VSS содержит значительные перемещения папок, то, скорее всего, вы потеряете всю историю до этого перемещения. Например, если вы переместите папку в новое место, а затем удалите предыдущий родитель, вы потеряете всю историю. Смотрите эту статью для более подробного объяснения: http://msdn.microsoft.com/en-us/library/ms253166.aspx

В одной миграции, с которой я был связан, у нас была 10-летняя база данных VSS, которая потеряла всю историю до 6 месяцев назад. Это произошло из-за значительной чистки, которая произошла 6 месяцев назад.

TFS инструмент преобразования <-- используйте это

Я уже несколько раз использовал этот инструмент, результаты довольно удовлетворительны, поскольку он поставляется с историей наборов изменений от SourceSafe, если вы тоже хотите.

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

Рекомендуется также выполнить анализ на SS, прежде чем запускать это.

Надеюсь, это поможет

Хорошее руководство там от моего бывшего коллеги Гая Старбака. Еще одна вещь, которую нужно добавить с этим подходом - вы, возможно, решили со временем, что вы хотите рефакторировать способ организации вашего приложения (папки и т. д.), И это даст вам возможность сделать это.

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

Что касается первоначального вопроса:

И: эта миграция наверняка будет означать, что наши рабочие привычки должны быть каким-то образом изменены. Считаете ли вы, что эти изменения могут стать проблемой для организации? Подумайте о группе из примерно 20 .net разработчиков, в одном сайте

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

1. Вы не должны использовать "Check-out" замков и "Get-Latest on Check-out".
2. Теперь вы можете эффективно ветвиться и сливаться
3. Теперь у вас будет "Changesets" все файлы, зарегистрированные одновременно, будут сгруппированы вместе. Это делает отслеживание исторических изменений намного проще , но что еще более важно-откаты намного проще (т. е. найти все файлы, зарегистрированные одновременно, и откатить их назад)
4. Связывание чеков с рабочими элементами. Не упускайте из виду рабочие элементы! Самая большая ошибка, которую вы можете сделать, - это использовать только TFS в качестве замены VSS. Функции сборки и управления проектами превосходны - вы заплатили за них - используйте их!

Что касается подробностей о том, как изменится ваш опыт, другой мой бывший коллега (и Team System MVP) Стив Сен-Жан написал подробную статью о различиях: от VSS до TFS