Решение
Вопрос ниже решения. Исходя из того, что Скотт Брунс предположил, что ветвление по версии может быть нашей проблемой, я решил тщательно прочитать документацию Team Foundation Server 2010, а также шаблоны и практики Microsoft. Используемые ресурсы:
Глава 5 - Определение стратегии ветвления и слияния
http://msdn.microsoft.com/en-us/library/bb668955.aspx
Я решил использовать следующую структуру.
TeamCollection
TeamProject
Development
Feature A
Feature B
Main
TeamApplication
Code
Project1
Project2
Project3
MyClassLibrary
Documents
Releases
1.0
2.0
2.1
Понимание этого довольно просто. Основная кодовая база находится в Main и содержит полную кодовую базу, но не несколько копий или несколько версий. Кроме того, если требуется разработка какого-либо компонента, отдельный проект может быть разветвлен в ветку разработки вместо того, чтобы разветвлять все решение. В результате изменения будут объединены с основным хранилищем. Это обеспечивает изоляцию, так что при разработке функции она не нарушает основную базу кода.
Итак, как это решает мою проблему поддержки различных сборок, так это то, что при выпуске новой сборки это сценарий, когда решение полностью разветвляется на Релизы. Так что, по сути, релизы содержат полную копию исходного кода для каждого выпуска, что имеет смысл. Таким образом, исправления, ошибки и обслуживание могут быть предоставлены для конкретных выпусков и объединены обратно с основным репозиторием, когда исправления и изменения будут стабильными.
Таким образом, в конечном итоге основная кодовая база по существу всегда будет последней стабильной сборкой программного обеспечения, в то время как разработка изолирует функции и непроверенный код, а выпуски изолирует ваши сборки и позволяет поддерживать после выпуска.
Другая часть проблемы, которая привела к решению, заключалась в том, что нам нужно было переходить для любого изменения, которое не является «исправлением». Понимая, что вы должны переходить только тогда, когда это абсолютно необходимо, мы теперь будем применять исправления, изменения и тому подобное к существующим базам кода и слиянию, а не создавать целые новые ветви.
Надеюсь, я хорошо это объяснил. Я все еще ощущаю Team Foundation Server 2010 и хорошо его изучаю. Множество ответов можно получить, внимательно прочитав документы MSDN, Шаблоны и Практики и тому подобное. Поначалу это трудно понять, но в конце концов вы понимаете.
Надеюсь, это поможет любому с похожим сценарием. Я по-прежнему отрывочно отношусь к хорошему методу ветвления функций, будь то разветвленная база кода от main или только отдельные проекты. Например, если нужно добавить только новый раздел WinForm, нужно иметь возможность просто ветвить файл формы, но без проекта у вас нет дизайнера, поэтому такие мелкие вещи кажутся проблемой.
Вопрос
Я провел некоторый поиск по ветвлению управления версиями здесь, в SO, в отношении ветвящихся структур и стратегий, но ни один из этих вопросов или ответов не соответствует моему конкретному сценарию, поэтому здесь мы идем.
Моя структура управления исходным кодом выглядит следующим образом:
TeamCollection
TeamProject
Code
1.0
Project1
Project2
Project3
MyClassLibrary
1.1
Project1
Project2
Project3
MyClassLibrary
2.0
Project1
Project2
Project3
MyClassLibrary
...
Обычный метод, который я использую для ветвления, состоит в том, чтобы просто разветвлять весь каталог версий. Скажем, я хочу сделать новую функцию из версии 2.0, я бы разветвлял всю папку 2.0 до 2.1.
Проблема, с которой я столкнулся при таком подходе сейчас, заключается в том, что размер этого проекта составляет 444 МБ, поэтому при моем текущем методе ветвления каждая версия составляет 444 МБ и использует много дискового пространства. Другая проблема заключается в том, что нет необходимости создавать дубликаты всех файлов, которые не нужно изменять.
В проекте у меня есть одна библиотека классов, которую я хотел бы ветвить с 2.0 до 2.1. Мне нужно сделать небольшое изменение в библиотеке, но я бы хотел отделить это изменение от базы кода 2.0. У меня возникла проблема с пониманием того, как мне перейти к этому.
Если я разветвляюсь следующим образом:
TeamCollection
TeamProject
Code
2.0
Project1
Project2
Project3
MyClassLibrary
2.1
MyClassLibrary
Я пытаюсь понять, как я мог бы создать выпуск всего продукта, но это включало бы версию 2.1 библиотеки классов, если она изолирована от других проектов. Я не обязательно хочу, чтобы база кода 2.0 была изменена для ссылки на библиотеку классов 2.1, потому что 2.1 не должна быть частью 2.0.
Мой другой подход заключался в следующем:
TeamCollection
TeamProject
Code
2.0
Project1
Project2
Project3
MyClassLibrary
MyClassLibrary-2.1 (following the default suggestion of TFS Explorer)
Это имеет некоторый смысл, так как ветвь 2.1 является подмножеством кода базы 2.0, потому что это незначительное изменение функциональности, но это также создает чрезвычайно грязную иерархию файловой системы для больших проектов, и я снова пытаюсь понять, как бы я собрал версию 2.1 всего проекта, не меняя ссылок в версии 2.0. Опять же, 2.1 должна быть отдельной сборкой от 2.0.
Мое единственное решение снова состоит в том, чтобы просто разветвлять весь проект, но я пытаюсь найти профессиональную помощь для этого, поскольку проект становится большим по размеру, и разветвление всех 444 МБ не должно быть необходимым.
Я хотел бы использовать первый вариант, который я предложил, где у меня есть 2.1 / MyClassLibrary, но мне действительно нужна помощь, чтобы понять, как я буду создавать сборку всего продукта только с одним проектом в каталоге 2.1.