TFS 2010: как обрабатывать внешние «разветвленные» зависимости от рабочих веток

Question

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

$/ThirdParty
  /bin
    /log4net

$/Product
  /Main
    /thirdparty
      /lognet      <-- $/ThirdParty/bin/log4net
  /Working1        <-- $/Product/Main
    /thirdparty
      /log4net     <-- $/Product/Main/lognet <-- $/ThirdParty/bin/log4net

Часть работы требует перестройки log4net с использованием профиля клиента .NET 4 и введения новой версии.Обычно, когда мы обновляем сторонний компонент, он регистрируется в $/Thirdparty в соответствующей папке, тогда отдельные проекты могут свободно объединять последний двоичный файл или нет, как они считают нужным.

НасколькоЯ могу определить, чтобы получить последний набор изменений из $/ThirdParty/bin/log4net, мне нужно объединить это в $/Product/Main, , проверить объединение в TFS , а затем объединить эту ветвь в $/Product/Working1.Это именно то, чего я хочу избежать, потому что я не хочу нарушать основную ветвь.

Итак, я предполагаю два вопроса:

1. Есть ли способзаставить это слияние работать без необходимости что-либо проверять в основной ветке?

2. Существует ли лучшая общая стратегия для обработки такого рода зависимостей при сохранении их в TFS?(Я знаю, что TFS не «предназначен» для двоичных файлов, но нам это нравится из-за легкого отслеживания нескольких версий и истории, которое мы из него получаем).

Answer 1

Ответ на 1:
Да.Вы можете сделать необоснованное слияние с ThirdParty на Working1.Вот страница MSDN:
http://msdn.microsoft.com/en-us/library/bb668976.aspx

Что касается 2: Если ваш основной проект может использовать более 2 разных версий вашего бинарного файла третьей стороны, то я рекомендую хранить отдельные версии бинарного файла стороннего производителяобласть $ / ThirdParty и не имеющая прямой связи между файлами в сторонней области и основной области.

Answer 2

Почему бы вообще не ликвидировать проект ThirdParty? Просто сохраните все версии сторонних библиотек в общей папке и отметьте соответствующую версию в дереве каждого проекта.