Заметки консультанта

TFS Branching Guide 2,0 довольно интересная сборка планов ветвления, которые основаны на практике применения Team Foundation Server. Будет полезно как пользователям TFS, так и интересно пользователям других систем версионного контроля. Страница проекта на CodePlex  – TFS Branching Guide 2,0

TFS Branching Guide – Main 2,0 – Это главная статья, которая коротко рассказывает о концепции ветвления и показывает 3 основные модели ветвления

TFS Branching Guide – Scenarios 2,0 – Набор наиболее общих сценариев ветвления

TFS Branching Guide – Q&A 2,0 – Частые вопросы и ответы

TFS Branching Guide – Drawings 2,0 – Изображения различных видов ветвлений в различных форматах файлов

TFS Branching Guide – Labs 2,0 – Примеры лабораторных работ с пошаговыми инструкциями их выполнения

Lab Files – Single Release Single Maintenance – Файлы для лабораторной работы «Single Release Single Maintenance»

< < Назад в TFS Branching Guidance – Q&A

Вопрос

Выполняя слияние между двумя ветвями с выбранной опцией «Все изменения до определенной версии», какой тип версии предпочтителен («Последняя версия» [по умолчанию], «Набор изменений», «Дата», «Метка» или «Версия рабочей области»)?

Ответ

В зависимости от выбранной опции будет определен различный набор изменений, как описано ниже:

• «Последняя версия» – все наборы изменений, которые не были объединены из исходной ветви от последней операции слияния, будут объединены с целевым потоком. Однако с момента последнего слияния в исходной ветви может вестись активная разработка, поэтому какие точно изменения будут объединены, может быть не четко определено.
  1. «Набор изменений» – все наборы изменений из исходного ветви, которые были зарегистрированы до указанного набора изменений, будут объединены с целевой ветвью (определение набора изменений эквивалентно определению даты, где дата – дата регистрации набора изменений).
     1. «Дата» – все наборы изменений исходной ветви, которые были зарегистрированы до указанной даты, будут объединены с целевым потоком.
        1. «Метка» – все наборы изменений, которые помечены в исходной ветви, будут объединены с целевым потоком. Поскольку метки в TFS не включают удаления, то изменения удаления, никогда не будут объединены в целевой ветви.
           1. «Версия рабочей области» – все изменения ветви до версий в указанном рабочем пространстве будут объединены с целевым потоком. Также как и для опции «Метка» изменения типа «удаление» не будут объединены.

Таким образом, т.к. присутствуют ограничения для опций «Метка» и «Версия рабочей области», не рекомендуется использовать слияние с этими опциями, если были изменения удаления.

Опция «Последняя версия» может использоваться, когда четко понятно, какие изменения будут содержаться в последней версии. Можно временно «заморозить» исходную ветвь на время проведения операции слияния с использованием блокировки до начала слияния.

Использование опций «Набор изменений» или «Дата» обеспечивает четкую контрольную точку для того, что будет объединено, и должно использоваться как правильное.

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

• «Deceptive Allure Of Merging With Labels» – http://blogs.msdn.com/tfsvcs/archive/2007/03/22/the-deceptive-allure-of-merging-with-labels.aspx

< < Назад в TFS Branching Guidance – Q&A

Вопрос

Можно ли удалять ветви?

Ответ

Удаление ветви не отличается от удаления любой папки системы управления версиями. Различие в том, что необходимо знать, не повлияет ли удаление ветви на дальнейшие операции слияния. Слияние в TFS возможно или на непосредственный родительский поток разработки, или на непосредственные дочерние ветви (если не выполняется слияние без базовой версии); таким образом, если промежуточный поток будет удален, то определенные пути слияния могут быть нарушены. Рассмотрим следующий пример:

• Есть ветвь от А к B
  1. Есть ветвь от B к C

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

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

• Смотрите раздел Baseless Merge руководства Branching Guidance
  1. «Team Foundation Server Permissions» – http://msdn.microsoft.com/ru-ru/library/ms252587(en-us,VS.80).aspx

< < Назад в TFS Branching Guidance – Q&A

Вопрос

Что такое слияние без базовой версии и чем оно отличается от обычного слияния?

Ответ

Слияние без базовой версии позволяет объединять две папки, которые не связаны ветками, создаваемыми через команду branch клиента командной строки tf или с помощью Обозревателя управления исходным кодом. Как только слияние без базы будет один раз выполнено, то в дальнейшем между этими папками можно будет выполнять обычное слияние (как будто эти папки связаны ветками). Хотя слияние без базовой версии может быть полезно для двух логически связанных каталогов, но не связанных ветками, в нем есть определенные недостатки по сравнению с обычной операцией ветвления/слияния:

• Операция слияния без базовой версии возможна только с использованием клиента командной строки tf.
  1. Связи, которые устанавливаются при выполнении слияния без базовой версии, не видны ни в клиенте командной строки tf, ни в Обозревателе управления исходным кодом (в том смысле, что команды tf branches и мастер слияния Обозревателя управления исходным кодом не работают с папками, которые связаны через слияние без базовой версии). Слияние без базовой версии можно определить только в истории слияний команды tf merge.
     1. Даже когда связь установлена через слияние без базовой версии, все дельнейшие операции слияния должны выполняться с использованием клиента командной строки tf.

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

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

• «How To: Perform a Baseless Merge» – http://www.codeplex.com/VSTSGuidance/Wiki/View.aspx?title=How%20To%3A%20Perform%20a%20Baseless%20Merge%20in%20Team%20Foundation%20Server&referringTitle=Whats%20New
  1. Смотрите раздел Baseless Merge руководства Branching Guidance

< < Назад в TFS Branching Guidance – Q&A

Вопрос

Когда создается новый командный проект, когда нужно использовать «Создать новую ветвь системы управления версиями»?

Ответ

При создании нового проекта, в диалоговом окне «Указание параметров системы управления версиями» находятся следующие пункты: «Создать пустую папку системы управления версиями», «Создать новую ветвь системы управления версиями» или «Не создавать в этот момент папку системы управления версиями».

При выбранном пункте «Создать новую ветвь системы управления версиями» создается новая папка системы управления версиями для проекта, которая будет содержать все данные, содержащиеся в папке системы управления версиями другого существующего проекта. Т.е. выбирая этот пункт, говорится, что «проект X будет содержать все исходные коды проекта Y».

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

Однако если существующий проект содержит несколько релизов (даже если они внутренние), то лучше использовать » Создать пустую папку системы управления версиями » для нового проекта, и затем выполнить ветвление от определенного каталога в существующем проекте, а не от корневой папки. Это позволит получить только необходимые каталоги, и даст более гибкое решение при формировании необходимой внутренней структуры нового проекта. Ниже диаграммы иллюстрируют подобную проблему:

Ветвление проекта

Ветвление каталога

< < Назад в TFS Branching Guidance – Q&A

Вопрос

Можно ли использовать ветвление между проектами?

Ответ

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

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

• Смотрите Branching and Team Projects в руководстве Branching Guidance