От Visual SourceSafe к Team Foundation ServerПреимущества перехода на современную платформу

От создателя Visual SourceSafe и Team Foundation ServerБрайана Харри

2

Разработано Майкрософт для перехода с VSS на TFS© 2010 Корпорация Майкрософт. Все права защищены.

Зачем вам этот переход?На момент выхода Visual SourceSafe (VSS) на рынок это был новейший инструмент управления версиями, отвечающий всем требованиям разработчиков. Интернета тогда практически не существовало, сети не были так распространены, приложения не работали с общими данными. Разработка велась преимущественно небольшими группами разработки, компактно расположенными территориально. Одним словом, все было намного проще, чем сейчас. В последние пятнадцать лет мы стали свидетелями бурного роста Интернета, разработки ПО и применения распределенных решений. Такой рост повлек за собой и повышение сложности создаваемых систем. Многим группам теперь необходима возможность удаленного доступа к коду, более простые методы отслеживания и аудита изменений в коде, высокая производительность и очень надежное хранилище исходного кода.

Реальность такова, что VSS не отвечает многим современным требованиям и, очевидно, достиг конечной точки своей эволюции. Майкрософт не планирует новых версий или обновлений к текущим версиям VSS. Преемником VSS является Team Foundation Server (TFS), и, учитывая все те преимущества, которые обеспечиваются переходом к Team Foundation Server, внедрять его необходимо уже сегодня!

2

Производительность, надежность и масштабируемость

Team Foundation Server использует SQL Server 2008 и, таким образом, перенял все преимущества производительности и масштабируемости ведущего в отрасли сервера баз данных уровня предприятия. Небольшие группы, которым не нужна мощь полнофункционального SQL Server, могут установить клиентскую ОС, такую как Windows 7, и использовать версию SQL Server Express – это та же мощная СУБД, но в более легковесном пакете. Таким образом, обеспечивается основное преимущество, которым никогда не обладал VSS: возможность начинать с малого и постепенно расти со временем. Перейти с SQL Server Express к полной версии SQL Server не сложнее, чем выполнить резервное копирование и восстановление. К другим преимуществам SQL Server относятся возможность динамического расширения хранилища по мере необходимости, более производительные операции чтения/записи и кластеризация как часть отказоустойчивого решения.

Благодаря тесной интеграции Team Foundation Server и Visual Studio пользователи получают привычную среду разработки с эффективной системой управления версиями. Как правило, при использовании Visual SourceSafe для выполнения задач по управлению версиями разработчикам приходилось открывать пользовательский интерфейс VSS вне Visual Studio. Интеграция Team Foundation Server с Visual Studio позволяет выполнять практически все операции с исходным кодом и рабочими элементами прямо в Visual Studio (для некоторых административных функций требуется полнофункциональная командная строка).

Одной из основных проблем установок VSS является ограничение размера хранилища исходного кода – 4 ГБ. В случае приближения к этому пределу или его превышения хранящийся исходный код может быть поврежден. Восстановление данных из резервной копии обычно связано с определенными сложностями, поскольку для этого группам приходится привлекать системных администраторов. И здесь, опять же, Team Foundation Server пользуется преимуществом мощи SQL Server. У SQL Server есть встроенная защита от повреждения данных. Однако если все-таки данные оказались повреждены, есть возможность их восстановления через функциональность резервного копирования SQL Server. SQL Server обеспечивает множество различных схем защиты данных – от добавочного и полного резервного копирования до доставки журналов и зеркального отображения базы данных – каждая из которых обеспечивает надежные механизмы защиты данных.

Безопасность

В VSS управление правами доступа сводится к трем настройкам: Admin (Администрирование), Read/Write (Чтение/Запись) и Read (Чтение). Применение настроек прав доступа на уровне файлов возможно, но сопряжено с массой сложностей. Это система доступа типа «все или ничего», что и является ее основным недостатком: если вы можете выполнять запись в файлы, значит, вы можете делать с ними, все что угодно. И поскольку все файлы хранятся в общей папке, каждый, кто имеет к ней доступ, может просто все удалить.

Тонкая настройка прав доступа, возможно, не является критически важной, но Team Foundation Server ее обеспечивает. Наряду с управлением правами доступа на файловом уровне группы также могут поддерживать особые сценарии, такие как возможность изъятия файла из системы управления версиями для редактирования разработчиком без последующей обязательной регистрации изменений в нем. Это удобно во многих ситуациях, например, для проведения экспертной оценки или удаленной разработки. И поскольку весь исходный код хранится на SQL Server, просто удалить его, как это было в VSS, теперь невозможно.

Дополнительные возможности

Разработчику иногда требуется знать, кто именно изменил конкретную строку кода в файле, и не только то, когда были внесены изменения, но и почему. Предоставляемая Team Foundation Server функция Annotate (Добавить аннотацию) обеспечивает именно эти возможности.

Преимущества Team Foundation Serverпо сравнению с Visual SourceSafe

3

Рисунок 1 - Аннотация в Team Foundation Server

На рис. 1 приведена аннотация к файлу, где для каждой строки кода указано, кем и когда она была добавлена. Это представление также позволяет получить детальные сведения о причинах внесения того или иного изменения (рис. 2). Здесь продемонстрировано и другое преимущество Team Foundation Server: атомарные регистрации изменений.

Рисунок 2 - Диалоговое окно сведений о наборе изменений

VSS не поддерживает атомарные регистрации изменений. Предположим, внесено изменение, затрагивающее три разных файла (a.cs, b.cs, c.cs), и его регистрация в VSS для одного из файлов дает сбой. Когда в следующий раз кто-либо из разработчиков попробует выполнить операцию Get, скорее всего, все закончится сбоем сборки из-за недостающих изменений, являющихся следствием частично неудачной регистрации изменений. При атомарной регистрации изменений регистрируются либо все файлы, либо не регистрируется ни один файл; третьего, промежуточного состояния, не дано. Это гарантирует, что зарегистрированный в системе управления версиями код всегда согласован. Кроме того, в VSS выяснить, какие файлы регистрировались вместе, можно только проверив временные метки каждого файла. В Team Foundation Server концепция атомарных наборов изменений является фундаментальной. На рис. 2 показано диалоговое окно Team Foundation Server. В нем четко представлены все

4

Рисунок 3 - Визуализация ветвления

Эта возможность обеспечивается одной из точек расширения: встроенным инструментом DiffMerge, который можно заменить любым другим инструментом сравнения и ориентировать на определенное расширение файла. Например, инструмент Beyond Compare производства Scooter Software может применяться для сравнения файлов кода, а DiffDog от Altova –XML-файлов. При появлении более совершенных инструментов сравнения и слияния, можно перейти к их использованию.

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

В VSS ветвление проблематично по нескольким причинам. Основная из них – невозможность визуализации структуры ветвления или движения кода по веткам. Кроме того, в VSS используется общий доступ, а не истинное ветвление, что может провоцировать конфликты, связанные с тем, где был предоставлен общий доступ к исходному коду и когда в него были внесены изменения. Это происходит, главным образом, потому что при общем доступе предоставляется ссылка на сам файл, а не на его копию. Поэтому изменения, вносимые в файл в одном проекте, могут приводить к сбоям в других проектах. В более поздних версиях VSS в дополнение к предоставлению общего доступа была введена концепция ветвления: сразу же после операции Share (Предоставить общий доступ) можно было выполнить операцию Branch (Выполнить ветвление) для кода. При этом фактически удалялась ссылка на файл и создавалась его копия. После этого, естественно, могло выполняться объединение.

Team Foundation Server использует чистую модель ветвления, здесь нет концепции предоставления совместного доступа. Ветвление способствует продвижению лучших практик разработки ПО и устраняет вероятность того, что изменения, внесенные в одном проекте, приведут к повреждению кода в другом проекте. В Team Foundation Server 2010 введена визуализация ветвления, благодаря чему группы могут видеть базовую структуру ветвей и движение кода. Более того, визуализация интерактивна: пользователи могут выполнять объединение прямо в ней (рис. 3).

5

Рисунок 3 - Визуализация ветвления

Отслеживание дефектов и задач с помощью рабочих элементов Team Foundation Server

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

Оповещения по электронной почте

Team Foundation Server позволяет разработчикам подписываться на оповещения по электронной почте об изменениях интересующих их файлов или папок. Для этого разработчик может щелкнуть правой кнопкой мыши файл или папку и выбрать в появившемся меню Alert on Change (Оповещение при изменении). При работе с Team Foundation Server вам не приходится проверять в журнале, изменялся ли важный для вас файл, вам сообщат об этом.

Наборы временно отложенных изменений

Название наборы временно отложенных изменений практически точно отражает суть этих элементов. Разработчик может отложить набор изменений «на полку»: временное хранилище в Team Foundation Server, в котором сохраняется резервная копия этих изменений, а также остальные файлы системы управления версиями. Разница в том, что файлы с временно отложенными изменениями не проходят процедуру регистрации в хранилище. Благодаря этому разработчики могут сохранять на сервере незавершенную работу в конце дня или выкладывать проблемный код для общего доступа без повреждения остального кода.

Автоматизированная сборка

Многие группы используют продукты сторонних производителей, которые обеспечивают периодическое извлечение исходного кода из VSS и его сборку. Группам, применяющим гибкие процессы разработки, как многие небольшие группы, такие дополнительные продукты могут обеспечивать выполнение сборки каждую ночь. Основная проблема такого подхода во введении еще одного набора инструментов и необходимости решения вопросов интеграции (т.е. совместимости). Team Foundation Server включает полностью автоматизированный масштабируемый сервер сборки, поддерживающий множество конфигураций. Также он поддерживает дополнительные возможности, такие как описание процесса сборки с помощью Windows WorkFlow 4.0 и расширяемость по всем аспектам.

6

Рисунок 4 - Visual SourceSafe

Рисунок 5 - Team Foundation Server

Отличительные особенности работыс VSS и Team Foundation ServerМы представили некоторые преимущества перехода на Team Foundation Server, но также полезно сравнить фактическое использование рассматриваемых инструментов. На рис. 4 и рис. 5 представлены интерфейсы Visual SourceSafe и Team Foundation Server, соответственно.

7

Эти интерфейсы очень похожи как по внешнему виду, так и по функциональности. В свое время организация и структура VSS были хорошо продуманы и теперь успешно перенесены во внешний вид и функциональность Team Foundation Server. Поэтому специалисты, ранее использовавшие VSS, не будут испытывать никаких сложностей при переходе к Team Foundation Server. Еще один момент, который необходимо вынести из рис. 4 и 5 – Team Foundation Server полностью интегрируется с Visual Studio. Отдельного пользовательского интерфейса для работы с Team Foundation Server нет. Благодаря этому большинство операций с системой управления версиями выполняется в одной среде, что способствует повышению производительности разработчиков. В табл. 1 представлены многие типовые операции VSS и их реализация в Team Foundation Server.

Таблица 1 – Сравнение некоторых общих для VSS и Team Foundation Server операций

Операция VSS Team Foundation Server

Изъятие файла из системы управления версиями для редактирования

Щелкните файл правой кнопкой мыши (в VSS или IDE) и выберите Check Out (Изъять для редактирования). Или можно начать редактирование файла, что спровоцирует операцию Get Latest (Получить последнюю версию), и файл будет изъят для редактирования.

Аналогично. В Team Foundation Server операция Get Latest при изъятии файла для редактирования является необязательной.

Регистрация изменений в файле в системе управления версиями

Щелкните файл правой кнопкой мыши (в VSS или IDE) и выберите Check In (Зарегистрировать изменения) или используйте окно Pending Checkins (Ожидающие регистрации изменения), как показано на рис. 6.

Аналогично. В Team Foundation Server окно Pending Checkins называется Pending Changes (Ожидающие регистрации изменения) (рис. 7).

Просмотр журнала

Щелкните файл правой кнопкой мыши (в VSS или IDE) и выберите View History (Просмотреть журнал).

Аналогично за исключением того, что Team Foundation Server не выводит на экран модальное диалоговое окно.

Получение версии

Щелкните файл правой кнопкой мыши (в VSS или IDE) и выберите Get (Получить). Для получения конкретной версии необходимо просмотреть журнал файлов, выбрать необходимую версию и щелкнуть Get.

Щелкните файл правой кнопкой мыши и выберите Get Latest. Чтобы получить конкретную версию, щелкните файл правой кнопкой мыши и выберите Get Specific Version (Получить конкретную версию). Выберите фильтр (по истории, дате, метке, последняя версия или версия рабочей области), задайте параметры запроса и щелкните Get.

Ветвление В VSS щелкните необходимую папку правой кнопкой мыши и выберите Share To (Предоставить общий доступ). Выберите папку, для которой хотите разрешить общий доступ, и щелкните Share (Общий доступ). Щелкните Recursive (Рекурсивно) и OK.

В обозревателе системы управления версиями щелкните правой кнопкой мыши папку и выберите Branching (Ветвление). Затем выберите Merging > Branch (Слияние > Ветвь). Щелкните OK.

Поиск со знаками подстановки

Откройте VSS и выберите View > Search (Wildcard or Status) (Вид > Поиск (Знак подстановки или Состояние)) и выберите соответствующие опции.

В обозревателе системы управления версиями щелкните правой кноп-кой мыши ветвь/папку/узел и выберите Find in Source Control (Wildcard or Status) (Найти в системе управления версиями (Знак подстановки или Состояние)) и выберите соответствующие опции.

Сравнение Щелкните правой кнопкой мыши файл или папку и выберите Show Differences (Показать отличия).

Аналогично. В Team Foundation Server эта(-от) команда/пункт меню называется Compare (Сравнить).

8

Рисунок 6 - Visual SourceSafe, панель Pending Checkins

Рисунок 7 - Team Foundation Server, панель Pending Changes

При взгляде на рис. 6 и 7 самое очевидное отличие в большем количестве доступных опций в Team Foundation Server (на рисунке окно Pending Changes видно не полностью, и на левой панели ниже границы рисунка имеются еще дополнительные опции). Во всем остальном, кроме дополнительных опций, работа с этими двумя инструментами практически ничем не отличается.

На рис. 8 и 9 сравниваются окна History (Журнал) в VSS и в Team Foundation Server.

Рисунок 8 - Диалоговое окно History в Visual SourceSafe

9

Рисунок 9 - Окно History в Team Foundation Server

При сравнении этих двух окон сразу можно увидеть несколько отличий: в диалоговом окне VSS есть столбец Version (Версия), и в диалоговом окне Team Foundation Server – столбец Changeset (Набор изменений). Это часть концепции, обсуждаемой в разделе «Дополнительные возможности» выше. Номера наборов изменений на сервере уникальны, тогда как номера версий VSS уникальны только для отдельного файла. Это означает, что в Team Foundation Server можно без проверки временной метки определить, какой набор изменений был зарегистрирован в системе управления версиями до или после любого другого набора изменений. Кроме того, увидеть, в каких наборах изменений участвует тот или иной файл, можно прямо в этом окне, выбрав вкладку Labels (Метки).

10

Возможность VSS ОписаниеКак эта возможность реализована в Team

Foundation ServerРасширение ключевого слова

Использование символов-заполните-лей в заголовке, подстановка которых выполняется при регистрации измене-ний в системе управления версиями (например, $Revision: $ заменяется на $Revision: 23 $, таким образом, мы знаем, что это 23 версия данного файла).

В настоящий момент TFS не поддерживает данную функциональность

Использование режима доступа только для чтения

Позволяет определять режим доступа к файлам (чтение/запись или только чтение) при их извлечении из хранилища системы управления версиями.

В настоящий момент TFS не поддерживает данную функциональность.

Откат изменений Возможность устанавливать в качестве последней версии файла его предыдущую версию.

TFS поддерживает эту функциональность, но в TFS 2010 она реализована только через командную строку (TF Rollback).

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

TFS не имеет такой встроенной функци-ональности, но она может быть без труда реализована через использование назначенного задания и выполнения команды TF Get для копирования файлов в файловый ресурс общего доступа.

Режим восстановления

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

Эта возможность не поддерживается в TFS. Временная метка файла всегда соответствует моменту времени выполнения операции Get для этого файла.

Поиск по содержимому файлов

Просмотр журнала

Выполнение поиска заданных слов в содержимом файлов.

В настоящее время поиск по содержи-мому файлов в TFS не поддерживается из-за специфики хранения данных в нем. Чтобы выполнить поиск, для файла необходимо выполнить операцию Get, переместить его на локальный жесткий диск и выполнять поиск локально, используя Windows Search или другую утилиту для поиска.

Что стало с основными возможностями?Некоторые возможности, доступные в VSS, в Team Foundation Server либо не поддерживаются, либо имеют другую реализацию. В табл. 2 представлен их список. Другие возможности, требующие более развернутого объяснения, такие как предоставление общего доступа (Sharing) и фиксация определенной версии файла (Pinning), обсуждаются ниже.

Таблица 2 – Как реализованы возможности VSS в Team Foundation Server

11

Предоставление общего доступа

Возможность предоставления общего доступа не поддерживается в Team Foundation Server. Здесь по ряду причин используется ветвление. Предоставление общего доступа является популярным решением в VSS, потому что при нем не требуется проводить слияния, и синхронизация файлов поддерживается автоматически. При предоставлении общего доступа, в противоположность ветвлению, создается ссылка на файл. Именно к этой ссылке и предоставляется общий доступ. При этом создается впечатление, что файл был скопирован в другой каталог, когда на самом деле это один и тот же файл. Это создает серьезные сложности для групп разработки, работающих над реализацией разных функций.

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

Все общие файлы и папки, имевшиеся в VSS, при переходе к Team Foundation Server будут преобразованы в отдельные файлы, т.е. будут создаваться фактические копии файлов, а не ссылки на них.

Фиксация определенной версии файла

Концептуально, фиксируя определенную версию файла, мы заявляем: «Это последняя гарантированно устойчиво работающая версия данного файла, и если вам нужна последняя версия, вы должны использовать именно этот файл». Благодаря этому разработчики получают возможность экспериментировать с последующими версиями, тогда как все остальные будут получать «фиксированную» рабочую версию. Фиксация версии защищает всех пользователей файла от ошибок, которые могут возникать в ходе дальнейшей работы над ним. Другое применение фиксации версии – определение версий файлов, которые должны быть включены в окончательную выпускаемую версию ПО.

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

12

Как выполнить миграцию с VSS на TFS?Существует два варианта перехода от VSS к TFS: миграция по состоянию на определенный момент времени и полная миграция. Независимо от выбранного варианта рекомендуется всегда сохранять резервную копию базы данных Visual SourceSafe, но важнее это делать при миграции по состоянию на определенный момент времени, поскольку так вы сохраните полную историю всех версий файлов.

Миграция по состоянию на определенный момент времени

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

1. Открыть Visual Studio и убедиться, что VSS является вашим поставщиком системы управления версиями: Tools > Options > Source Control (Инструменты > Опции > Система управления версиями). 2. Откройте проект, который требуется конвертировать, и выполните для него операцию Get Latest. 3. Выберите File > Source Control > Change Source Control (Файл > Система управления версиями > Изменить систему управления версиями). 4. Удалите привязку решения и всех проектов и щелкните OK. 5. Закройте решение и щелкните в диалоговом окне с предложением сохранить изменения Yes (Да). 6. Задайте TFS в качестве поставщика системы управления версиями (Tools > Options > Source Control). 7. Откройте обозреватель системы управления версиями: View > Other Windows > Source Control Explorer (Вид > Другие окна > Обозреватель системы управления версиями). 8. Убедитесь, что групповой проект создан. Если нет, создайте его. 9. Выберите проект, в который хотите переместить файлы, и спроецируйте его каталог на локальный жесткий диск. 10. Скопируйте выбранное решение из существующего каталога в каталог, созданный в Шаге 9. 11. Откройте скопированное решение в Visual Studio. 12. Щелкните решение правой кнопкой мыши и выберите в появившемся меню Add Solution to Source Control (Добавить решение в систему управления версиями). 13. Зарегистрируйте ожидающие регистрации изменения в системе управления версиями.

Теперь решение и все его проекты полностью находятся в Team Foundation Server.

Полная миграция

Для полной миграции необходимо выполнить несколько шагов в строго определенном порядке. Здесь приводится полное руководство, и дополнительные ссылки указаны в разделе ссылок в конце данного документа.

1. Убедитесь, что на компьютер установлены VSS и обозреватель проекта Team Explorer. 2. Убедитесь, что установлена версия VSS 2005.

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

3. Установите KB947647.

http://code.msdn.microsoft.com/KB947647/Release/ProjectReleases.aspx?ReleaseId=1028.

13

Этот пакет исправляет известные проблемы, которые часто возникают при преобразовании файлов из VSS в Team Foundation Server с использованием VSSConverter.

4. Выясните пароль администратора для VSS. 5. Создайте файл параметров анализа (ниже приведен пример такого файла) в папке, которая является частью проекта, либо в %programfiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE. Для целей данного описания назовите его analysissettings.xml

<?xml version=”1.0” encoding=”utf-8”?><SourceControlConverter><ConverterSpecificSetting> <Source name=”VSS”> <VSSDatabase name=”c:\VSSDatabase”1></VSSDatabase> <UserMap name=”c:\Migrate\Usermap.xml”2></UserMap> <SQL Server=”SQL Server Name”3></SQL> </Source> <ProjectMap> <Project Source=”$/FolderA”4></Project> <Project Source=”$/FolderB”></Project> </ProjectMap></ConverterSpecificSetting><Settings> <Output file=”Analysis.xml”5></Output></Settings></SourceControlConverter>

6. Откройте утилиту командной строки Visual Studio 2010 и введите следующую команду:

Vssconverter analyze analysissettings.xml

Если вы работаете под учетной записью администратора, это можно сделать в обычной командной строке. Приложение VSSConverter.exe находится в папке %programfiles(x86)%\ Microsoft Visual Studio 10.0\Common?\IDE. Если файл analysissettings.xml создать в другой папке, придется указывать полный путь к нему. Vssconverter проводит анализ analysissettings.xml.

7. По завершении анализа убедитесь в отсутствии ошибок и проверьте, насколько серьезные предупреждения были сформированы. Большинство предупреждений – это просто информационные сообщения. Если возникли какие-то ошибки, устраните их и повторяйте команду из Шага 6 до тех пор, пока не добьетесь безошибочного выполнения.

8. Настройте структуру проекта в Team Foundation Server (т.е. создайте групповые проекты, в которые хотите перенести код из VSS).

9. Создайте файл параметров миграции (ниже приведен пример такого файла). Для целей данного описания назовите его migrationsettings.xml.6

1 Путь к базе данных VSS – папка, в которой находится файл srcusers.ini.2 Файл Usermap.xml будет создан автоматически, а это путь к папке (включая имя файла), в которой он будет размещен. Поэтому, если хотите поместить все в каталог c:\migration, прежде всего убедитесь, что c:\migration существует, каталоги не создаются автоматически.3 Используйте SQL Server, если размер базы данных VSS превышает 4ГБ (по умолчанию VSS Converter использует SQL Express, который не может сохранять более 4ГБ данных). 4 Это исходные папки в VSS. $/ представляет корневой каталог VSS, используйте его для анализа всего хранилища VSS сразу.5 Это файл анализа, который создается после выполнения vssconverter. По умолчанию он сохраняется в папку, из которой выполняется vssconverter, но по желанию можно задать для него полный путь.6 Если в файле параметров анализа использовался тег SQL Server, применяйте его и здесь.

14

10. Обновите Usermap.xml.

Каждому пользователю, указанному в данном файле, должно быть сопоставлено действительное имя AD, обладающее, по крайней мере, правами чтения в Team Foun-dation Server. Важно добавить пользователей сначала в Team Foundation Server. Также обратите внимание, это не обязательно должно быть строгое сопоставление. Если сотрудник покинул компанию, и для него нет соответствующей записи в AD, его можно просто сопоставить с другим сотрудником. Эти данные используются при регистрации файла в системе управления версиями, но в комментариях к регистрации изменений указывается исходное имя пользователя.

11. Из командной строки Visual Studio 2010 выполните следующую команду:

Vssconverter migrate migrationsettings.xml

После этого должно быть выполнено преобразование, и все должно пройти гладко. Не забудьте задать Team Foundation Server как поставщика системы управления версиями в Visual Studio. Для этого в главном меню Visual Studio выберите:

Tools > Options > Source Control and select Visual Studio Team Foundation Server.

<?xml version=”1.0” encoding=”utf-8”?><SourceControlConverter> <ConverterSpecificSetting> <Source name=”VSS”> <VSSDatabase name=”c:\VSSDatabase”></VSSDatabase> <UserMap name=”c:\Migrate\Usermap.xml”7></UserMap> </Source> <ProjectMap> <Project Source=”$/FolderA” Destination=”$/TeamProjectA”8/> <Project Source=”$/FolderB” Destination=”$/TeamProjectB/ProjectB” /> </ProjectMap> </ConverterSpecificSetting> <Settings> <TeamFoundationServer name=”My_TFS_Server” port=”8080” protocol=”http” collection=”tfs/DefaultCollection”></TeamFoundationServer> <Output file=”Migration.xml”9></Output> </Settings></SourceControlConverter>

7 В данном контексте это путь к файлу usermap.xml, созданному на этапе анализа.8 Это фактическое сопоставление , соответственно которому TFS размещает код. В шаге 6 выше вы должны были создать групповые проекты, в которые будут проецироваться данные проекты. Также обратите внимание, что не обязательно проецировать их в корневой каталог. Скажем, в VSS есть папка «$/MyProject», и вы хотите переместить ее в TFS в папку «$/MyProject/Root/Dev»; вы можете сделать это.9 Этот файл создается автоматически. По желанию для него можно задать полный путь.

15

Как приобрестиTeam Foundation Server?С выходом Visual Studio 2010 Team Foundation Server 2010 включен как привилегия подписки

MSDN со следующими клиентскими инструментами: Visual Studio 2010 Professional, Visual

Studio 2010 Premium, Visual Studio 2010 Ultimate и Visual Studio Test Professional 2010. Каждая

подписка MSDN дает право на развертывание одного экземпляра Team Foundation Server для

производственной эксплуатации. Кроме того, каждая подписка MSDN включает клиентскую

лицензию доступа (CAL) для Team Foundation Server. Таким образом, разработчикам не надо

больше ничего покупать и продлять: приобретая Visual Studio 2010 Professional, Premium, Ultimate

или Test Professional они получают все необходимое для работы с Team Foundation Server.

В случае отсутствия подписки MSDN Team Foundation Server можно приобрести в сети

розничной торговли или в онлайн-магазине Майкрософт. Эта лицензия дает право работать

с этим экземпляром Team Foundation Server до пяти (5) пользователям без необходимости

получения CAL. Все пользователи сверх этого количества должны приобретать CAL.

Team Foundation Server – будущее, которое доступно уже сегодняКак мы выяснили, работа с Team Foundation Server в качестве системы управления версиями мало

отличается от работы с VSS. За редким исключением, Team Foundation Server обеспечивает все

функции VSS и множество дополнительных возможностей. Вероятно, Team Foundation Server

с настройками по умолчанию не будет точно повторять VSS, и вам, возможно, придется кое-

что подкорректировать. Но основная идея в том, что Team Foundation Server будет работать

именно так, как вы хотите, и обеспечивать такие преимущества, как использование SQL

Server для хранения, гарантированная целостность данных, масштабируемость, надежность,

низкие затраты на обслуживание и высокая производительность. Все это упрощает жизнь

разработчиков, теперь они могут тратить меньше времени на обслуживание исходного кода и

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

Team Foundation Server и отслеживания рабочих элементов, Team Foundation Server дает

пространство для роста приемлемыми для вас темпами – вы не обязаны использовать те

функции и инструменты, которые не хотите использовать. Team Foundation Server заменил VSS

и пришло время двигаться дальше. Подписчики MSDN уже имеют Team Foundation Server 2010 в

своем распоряжении. Те, у кого нет подписки MSDN, могут загрузить ознакомительную версию

по адресу http://www.microsoft.com/downloads.

16

17

СсылкиЗдесь собраны ссылки на все страницы, посвященные миграции:

VSSConverter Command-Line Utility for Source Control Migration (Утилита командной строки VSSConverter для миграции системы управления версиями)http://msdn.microsoft.com/en-us/library/ms253090.aspx

Walkthrough: Migrating from Visual SourceSafe to Team Foundation (По шагам: миграция с Visual SourceSafe на Team Foundation)http://msdn.microsoft.com/en-us/library/ms181247.aspx

Analyze Command (VSSConverter) (Команда Analyze (VSSConverter))http://msdn.microsoft.com/en-us/library/ms400803.aspx

Migrate Command (VSSConverter) (Команда Migrate (VSSConverter))http://msdn.microsoft.com/en-us/library/ms400685.aspx

How to: Create a Settings File for Source Control Analysis and Migration (Руководство по созданию файла параметров для анализа и миграции исходного кода)http://msdn.microsoft.com/en-us/library/ms253161.aspx

Sample VSS Converter Settings File (Пример файла настроек VSSConverter)http://msdn.microsoft.com/en-us/library/ms253123.aspx

How to: Edit the Source Control Migration User Mapping File (Руководство по редактированию файла сопоставления пользователей при миграции системы управления версиями)http://msdn.microsoft.com/en-us/library/ms253175.aspx

© 2010 Корпорация Майкрософт. Все права защищены.