Вопросы и ответы: система управления исходным кодом и версиями TFS

Администрирование

• Как предоставить разрешение на доступ к файлу в папке, имеющей наследуемые разрешения?
• Что делать, если разработчик покидает проект?
• Как управлять стажерами и другими разработчиками, которым я не доверяю возвращать правки на сервер?
• Как следует изменять разрешения после отправки приложения заказчику?

Как предоставить разрешение на доступ к файлу в папке, имеющей наследуемые разрешения?

Чтобы задать разрешения, щелкните правой кнопкой папку или файл в окне Source Control Explorer, выберите команду Properties и перейдите на вкладку Security. Далее выберите пользователя или группу, для которых хотите изменить разрешения, и отредактируйте разрешения в списке Permissions.

Задавать разрешения можно также из командной строки с помощью подкоманды Permission, входящей в состав утилиты TF.

Система Team Foundation Source Control позволяет управлять доступом для групп Windows Groups, Windows Users и Team Foundation Groups. Разрешения могут наследоваться из папки более высокого уровня или задаваться явно.

Разрешения имеют вид разрешения ( Allow ) или запрета ( Deny ). Запрет всегда перекрывает разрешение, даже если Deny является наследуемой формой, а форма Allow объявлена явно. Фактические разрешения на доступ к объекту для пользователей или групп определяются комбинацией наследуемых и явных разрешений. Поскольку Deny всегда перекрывает Allow, можно не отключать наследование, чтобы, например, запретить возврат после правки.

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

Дополнительные ресурсы

• Дополнительную информацию о разрешениях вы найдете в статье "Team Foundation Server Default Groups, Permissions, and Roles" on MSDN по адресу http://msdn2.microsoft.com/en-us/library/ms253077.aspx.
• Дополнительную информацию о разрешениях вы найдете в статье "Source Control Security Rights and Permissions" on MSDN по адресу http://msdn2. microsoft.com/en-us/library/ms181761.aspx.

Что делать, если разработчик покидает проект?

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

Примечание Если в командном проекте включена исключающая блокировка, вы не сможете отменить блокировки, не отменив изменения.

Чтобы узнать, какие файлы заблокированы пользователем, запустите следующую команду: tf workspaces /owner:domain\devuser /computer:* /server:servername

Для удаления рабочей области и снятия блокировок выполните команду Tf workspace /delete workspacename;domain\devuser /s:servername

Дополнительные ресурсы

• Дополнительную информацию о том, что следует предпринять после ухода разработчика из проекта, вы найдете в статье "How to: Clean Up Files When Users Leave" по адресу http://msdn2.microsoft.com/en-us/ library/ms194958(VS.80).aspx.
• Дополнительную информацию о команде Workspace вы найдете в статье "Workspace Command" по адресу http://msdn2.microsoft.com/en-us/ library/y901w7se(VS.80).aspx.

Как управлять стажерами и другими разработчиками, которым я не доверяю возвращать правки на сервер?

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

Дополнительные ресурсы

• Дополнительную информацию об удалении разрешений вы найдете в статье "How to: Remove Access to Source Control Files" по адресу http://msdn2.microsoft.com/en-us/library/ms400718(VS.80).aspx.

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

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

Дополнительные ресурсы

• Дополнительную информацию об удалении разрешений вы найдете в статье "How to: Remove Access to Source Control Files" по адресу http://msdn2.microsoft.com/en-us/library/ms400718(VS.80).aspx.

Ветвление, метки и слияние

• Когда использовать метки?
• В чем отличие меток TFS от меток VSS?
• Что такое ветвление?
• Когда следует выполнять ветвление?
• Когда не следует выполнять ветвление?
• Как использовать ветвление для выпуска приложения?
• Как использовать ветвление для поддержки приложения?
• Как при помощи ветвления сократить количество конфликтов между командами?
• Как при помощи ветвления сократить количество конфликтов в компонентах?
• Как наиболее эффективно провести ветвление и слияние?
• В чем разница между ветвлением и метками?
• Что представляет собой модель ветвления в пространстве путей?
• Что такое модель распространения TFS?
• Как выполнить слияние двух ветвей?
• Можно ли выполнить слияние между командными проектами?
• Что такое слияние без основы?
• Что такое модель продвижения кода?
• В чем отличие между логическим и физическим представлениями ветвей?
• Как часто следует выполнять слияния?

Когда использовать метки?

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

Система Team Foundation Build автоматически помечает версии файлов, связанные каждой создаваемой сборкой.

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

Дополнительные ресурсы

• Дополнительную информацию о метках вы найдете в статье "Working with labels" по адресу http://msdn2.microsoft.com/en-us/library/ms181439 (VS.80).aspx.
• Дополнительную информацию о применении меток вы найдете в статье "How to: Apply Labels" по адресу http://msdn2.microsoft.com/en-us/library/ ms181440(VS.80).aspx.

В чем отличие меток TFS от меток VSS?

Метки Team Foundation Server отличаются от меток VSS довольно сильно. Поскольку метки VSS являются метками времени и присваиваются, как правило, всему дереву VSS или его части, система отображает метки в хронологической последовательности вместе с историей файлов. Все, что стоит в списке до помеченного файла, включается в метку, а все, что стоит после - не включается.

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

Дополнительные ресурсы

• Сравнительную характеристику меток TFS и VSS вы найдете в статье "Comparing SourceSafe Labels to Team Foundation Server Labels" по адресу http://blogs.vertigosoftware.com/teamsystem/archive/2006/05/03/Comparing_SourceSafe_Labels_to_Team_Foundation_Server_Labels.aspx.

Что такое ветвление?

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

При ветвлении TFS не создает отдельные копии содержимого файла, поэтому само ветвление не требует значительного дополнительного пространства в БД системы управления исходным кодом. Ветвь содержит указатель в БД на исходный код и список отличий текущего содержимого от базовой версии.

Дополнительные ресурсы

• Вводный курс по ветвлению и слиянию можно прочитать в статье "Branching and Merging Primer" по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.
• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181425(VS.80).aspx.
• Дополнительную информацию о слиянии вы найдете в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181428(VS.80).aspx.
• Подробнее о методах ветвления и слияния в Visual Studio 2005 читайте в статье "Branching and Merging Team Foundation Source Control" по адресу http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx.

Когда следует выполнять ветвление?

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

Для принятия решения по поводу создания ветви ответьте на один вопрос - что больше: затраты на разрешение конфликтов слияния в реальном времени или накладные расходы на разрешение конфликтов слияния между ветвями?

Общие основания для создания ветвей таковы:

• Выпуск Изоляция нескольких параллельных выпусков.
• Обслуживание Сопровождение ранее выпущенной сборки.
• Компонент Изоляция работы над экспериментальными или рискованными компонентами, которые могут внести неустойчивость в остальной проект.
• Команда Изоляция подгрупп, чтобы оградить их от нежелательного влияния изменений друг друга. Изолированные группы могут стремиться к различным контрольным вехам. Ветви команд схожи с ветвями компонентов.

Дополнительные ресурсы

• Вводный курс по ветвлению и слиянию можно прочитать в статье "Branching and Merging Primer" по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.
• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181425(VS.80).aspx.
• Дополнительную информацию о слиянии вы найдете в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181428(VS.80).aspx.
• Подробнее о методах ветвления и слияния в Visual Studio 2005 читайте в статье "Branching and Merging Team Foundation Source Control" по адресу http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx.

Когда не следует выполнять ветвление?

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

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

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

Дополнительные ресурсы

• Вводный курс по ветвлению и слиянию можно прочитать в статье "Branching and Merging Primer" по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.
• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181425(VS.80).aspx.
• Дополнительную информацию о слиянии вы найдете в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181428(VS.80).aspx.
• Подробнее о методах ветвления и слияния в Visual Studio 2005 читайте в статье "Branching and Merging Team Foundation Source Control" по адресу http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx.

Как использовать ветвление для выпуска приложения?

Создайте ветвь Release, когда будете готовы зафиксировать сборку перед выпуском приложения. Далее приводится пример структуры ветвей после создания ветви выпуска:

• Main - главная ветвь сборки.
  • Source.
  • Другие папки ресурсов.
• Release 1 - Ветвь выпуска.
  • Source

Учитывайте следующие рекомендации по работе с ветвью выпуска:

• Когда выполнять ветвление Подготовившись к выпуску, соберите все в главную ветвь ( Main ), а затем создайте ветвь выпуска ( Release ), целью которой будет стабилизация приложения перед выпуском.
• Когда не следует выполнять ветвление Если каждому выпуску соответствует отдельный проект TFS, используйте для продолжения разработки новый проект, не выполняя ветвление текущего проекта.
• Разрешения на доступ к ветви:
  • Перед выпуском - разрешения на чтение и запись для всех разработчиков.
  • После выпуска - разрешения на чтение и запись разработчикам, принимающим участие в работе над исправлениями, всем остальным - разрешения только на чтение.
• Частота сборок в ветви По мере необходимости.
• Тесты в ветви Прекращаются после выпуска.

Ветвь Release следует использовать только для внесения целевых исправлений и изменений, требуемых для стабилизации сборки перед выпуском. Разработка следующих версий приложения может параллельно продолжаться в ветвях сборки Development или Integration. Благодаря этому в версию, готовящуюся к выпуску, можно будет до даты выпуска вносить все возникающие стабилизирующие изменения. После создания окончательной сборки выпуска вы можете провести слияние изменений из ветви Release в ветви сборки Development или Integration.

Дополнительные ресурсы

• Вводный курс по ветвлению и слиянию можно прочитать в статье "Branching and Merging Primer" по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.
• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181425(VS.80).aspx.
• Дополнительную информацию о слиянии вы найдете в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181428(VS.80).aspx.
• Подробнее о методах ветвления и слияния в Visual Studio 2005 читайте в статье "Branching and Merging Team Foundation Source Control" по адресу http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx.