Филиал TFS 2010 во всех командных проектах - лучшие практики

У меня возникли проблемы с пониманием того, как настроить TFS в соответствии с лучшими практиками, предоставленными командой TFS Ranger. Проблема такова:

В моей компании есть несколько продуктов, которые используют общую общую базу кода.

> $/Core
>  -> /Main/Source (Parent Branch)
> 
> $/Product1
>  -> /Main/Source
>  -> /Main/Source/Core/Source (Child Branch from $/Core)
>  -> /Main/Source/...
> 
> $/Product2
>  -> /Main/Source
>  -> /Main/Source/Core/Source (Child Branch from $/Core)
>  -> /Main/Source/...

Поэтому у нас есть один коллектив команды и, скажем, три командных проекта для этого примера. ($/* - командный проект)

Наша начальная ветвь релиза - это немного боль. Вместо того, чтобы разветвляться на /Main to/Releases или /Main to/Development, мы разветвляем каждый проект по отдельности. (Проект не проект проекта...).

Это связано с невозможностью иметь вложенные корни ветвей. (См. Ошибки TFS: TF203028 и TF203071)

В соответствии с TFS Ranger Guide и нашим пересмотренным подходом к выпуске ветвей, исправлениям, событиям мы должны разветвляться от /Main, а не /Main/Source/Proj 1,/Proj2,/Proj3 и т.д. Это просто становится довольно большим досадой.

В идеале мы хотели бы:

> $/Product1
> -> /Main/ (Branch - Parent)
> -> /Releases
>    -> /1.x
>       /1 Service Pack (Child Branch from $/Product1/Main
>       -> /1.0
>          -> /1.0 Hotfix (Child Branch from $/Product1/Releases/1.x/1 Service Pack)
>          -> /1.0 RTM (Child Branch from $/Product1/Releases/1.x/1.0/1.0 Hotfix - Read Only)
>          -> /1.0.22 RTM (Child Branch from $/Product1/Releases/1.x/1.0/1.0 Hotfix - Read Only)
>       -> /1.5
>          -> /1.5 Hotfix (Child Branch from $/Product1/Releases/1.x/1 Service Pack)
>          -> /1.5 RTM (Child Branch from $/Product1/Releases/1.x/1.5/1.5 Hotfix - Read Only)

Решения: 1. Мы можем преобразовать каждую общую ветвь (т.е. $/Core) обратно в обычные папки. Таким образом, папка под /Main не является корнем ветки. Затем мы можем выполнить необоснованное слияние из $/Product1/Main/Source/Core/Source обратно в родительский $/Core/Source.

Есть ли у кого-нибудь какой-либо опыт с необоснованными слияниями. То, что я прочитал от Microsoft, - это исключения, которые не должны быть обычным явлением. MS заявляет, что если вы правильно настроили свои проекты с помощью TFS, вам никогда не понадобится выполнять необоснованное слияние.

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

Я также открыт для других решений.

Спасибо!

Ответ 1

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

Я знаю, что считается хорошей идеей строить из исходного кода везде, где это возможно, но я не фанат ветвления между командными проектами. Если у вас есть какой-то общий код, и его нужно разветкить между 2 или 3 другими командными проектами, тогда ветвление управляемо, но если у вас есть 20 или 30 (или 100) командных проектов, то управление объединениями становится головной болью. Могут быть и другие проблемы, если разработчики, работающие в командных проектах-потребителях, не имеют одинаковых разрешений в "главном", например, не могут просматривать историю и т.д. Конечно, если у вас есть код, который необходимо совместно использовать в командных проектах в разных коллекциях проектов, тогда вы все равно не сможете разветвляться.

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

У вас может быть сборка для вашего общего кода, копирующая двоичные файлы в место размещения, вместе с модулем слияния для упаковки (если вы используете MSI). Затем вы создаете двоичную ссылку на место размещения и получаете все, что используете для упаковки, для импорта модуля слияния. В этом сценарии вы должны убедиться, что место отбрасывания стабильно (и желательно только для чтения большинству разработчиков, чтобы предотвратить вмешательство)
Аналогично варианту 1, но для управления ссылками используется такой инструмент, как NuGet, это автоматизирует процесс обращения к новым версиям двоичных файлов.
Вы можете просто проверить двоичные файлы в папке $/Product1/branch/lib/common в вашей ветке и ссылаться на них, используя относительный путь

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

РЕДАКТИРОВАТЬ: После 8 лет размышлений об этом пакеты Nuget - это путь вперед. Я оставил остальную часть ответа на месте, так как он все еще получает мнения и положительные голоса. Встраивание зависимостей в пакеты и хранение их в бинарном хранилище (nuget/Nexus/Artifactory/Azure Artifacts и т.д.) Является в значительной степени стандартным способом решения этой проблемы.

Ответ 2

Ветвление TFS 2010:

Я хотел бы предложить режим доверия для функции беспочвенного слияния TFS 2010 как способ решения этой проблемы. Я очень рекомендую забрать книгу Wrox "Профессиональный Team Foundation Server 2010".

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

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

Ответ 3

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

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

tf merge /baseless "D:\TFS2010\Root\ServicePack" "D:\TFS2010\Root\MainLine" /recursive

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

Для этого нажмите на ветку ServicePack (как показано в моем примере), а затем в меню файла выберите "Управление источником" → "Ветвление и слияние" → "Восстановить". Там у вас будет возможность перевоспитания. После этого, следовательно, когда вы хотите объединиться через эти ветки, вы сможете делать это, как обычное слияние по ветвям.

Ответ 4

Я настраивал TFS только сейчас и столкнулся с той же проблемой. Дело в том, что нет необходимости в беспочвенном слиянии. Обход проблемы:

Создать родительскую ветку

$/ядро /Main
Создать дочернюю ветвь

$/Product1
- > /Главная
- > /Главная/Основные
- > /Главная/...
удалить дочернюю папку

$/Product1/Главная/Core
Создайте папку с именем SAME

$/Product1/Главная/Core
Конвертировать папку Product1 в ветку

$/Product1/Main

Теперь вы можете объединить изменения с $/Core/Main на $/Product1/Main/Core и наоборот.
Визуализация не будет работать для ветки Core, но это нормально, я думаю;)

Ответ 5

Если вы хотите поделиться общим кодом, попробуйте следующее решение:

Перейдите на File-> Source Control-> Добавить проект из Source Control...

Появится диалоговое окно, позволяющее добавить проект из другого места в системе контроля версий.

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

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

Оригинальный ответ