TFS2010: Получить все ревизии, связанные с веткой (полная рекурсия )

Это следует из моего предыдущего вопроса о TFS 2010 и возможности создания журнала изменений.

Раньше я использовал метки для идентификации версии программы, но поскольку метки не являются фиксированными точками времени, теперь я использую ветки.

Вот как выглядит иерархия ветвей:

Как видите, есть два разных приложения, которые являются ветвями магистрали: APP_A (приложение A) и APP_B (приложение Б). Оба практически идентичны, но есть некоторые функциональные различия.

Вот процесс создания новой версии приложения (скажем, версии 1.3):

1. Основной канал изменен (добавлены новые функции, исправлены ошибки ...)
2. Из измененной основной магистрали создается новая ветка: Основная магистраль 1.3
3. APP_A ветка может быть изменена, поэтому уникальные функции APP_A будут работать с модификация ветки v1.3
4. APP_B может быть изменена, поэтому уникальные функции APP_B будут работать с модификацией v1.3
5. Основная магистраль 1.3 объединена с ] APP_A и APP_B , поэтому оба приложения APP_A и APP_B получают модификации основной магистрали
6. Из измененной ] APP_A ветка, создается новая ветка: APP_A_1.3
7. Из измененной ветки APP_B создается новая ветка: APP_B_1.3

My цель быть в совершенстве e для создания журнала изменений между APP_A_1.3 и APP_A_1.2 .

Под журналом изменений я подразумеваю список рабочих элементов. Каждый зарегистрированный набор изменений связан с одним или несколькими WorkItem (например, с элементом Bug). Я хотел бы получить список всех рабочих элементов, которые были связаны с набором изменений, который повлиял на APP_A_1.3 : эти наборы изменений могут поступать из Main trunk ( шаг 1 выше), ветвь APP_A (шаг 3 выше) или даже сама ветка APP_A_1.3 (если исправления регистрируются после создания ветки).

Чтобы получить этот список рабочих элементов, я попытался получить список всех наборов изменений, которые «связаны» с APP_A_1.2 ( «connected» = проверенный код -in в наборе изменений теперь находится в ветке APP_A_1.2 ) и в списке всех наборов изменений, которые «связаны» с APP_A_1.3 .

Тогда я смогу узнать, какие наборы изменений «связаны» с APP_A_1.3 , а не «связаны» с APP_A_1.2 . Из этого набора изменений я получу все связанные рабочие элементы и, следовательно, мой журнал изменений.

Вот моя проблема: как мне получить список ВСЕХ ревизий, которые «связаны» с указанной веткой? Я использую API TFS 2010 для кода C #.

Входными данными моей программы (которая будет извлекать все ревизии для указанной ветки) будет имя ветки (скажем, APP_A_1.2 ), а на выходе будет список следующих ревизий:

• ревизий, примененных к APP_A_1.2 ветке
• ревизий, примененных к APP_A ветке до создания APP_A_1.2
• ревизий, примененных к Главный ствол 1.2 ветвь до того, как она была объединена с APP_A
• набором изменений, примененных к Main trunk ветке до создания Main trunk 1.2

Я написал следующие фрагменты кода для получения всех этих изменений:

// Gets the list of all changesets ID from APP_A_1.2 branch
var branch1ChangeSets = myVersionControlServer.QueryHistory(
    "$/PATH/APP_A_1.2/",
    VersionSpec.Latest,
    0,
    RecursionType.Full,
    null,
    null,
    null,
    int.MaxValue,
    false,
    false).OfType().Select(z => z.ChangesetId).ToList();

Даже если указан RecursionType.Full , приведенный выше код только возвращает наборы изменений, которые были зарегистрированы в APP_A_1 .2 филиал. Это идентично команде «История» в представлении «Обозреватель исходного кода» в Visual Studio.

Затем я попробовал следующий фрагмент кода:

// Gets the list of all changesets ID from APP_A_1.2 branch
var branch1MergedChangeSets = myVersionControlServer.QueryMerges(
    null,
    null,
    "$/PATH/APP_A_1.2/",
    VersionSpec.Latest,
    null,
    null,
    RecursionType.Full).Select(z => z.SourceVersion).ToList();

Он возвращает наборы изменений, которые были зарегистрированы на ветке APP_A_1.2 + те, которые были проверены на ветке APP_A до создания APP_A_1.2 . Намного лучше, но этого недостаточно. Я не могу найти способ заставить рекурсию работать с ветвями, которые находятся «выше» APP_A ( Main trunk в моем случае) ...

У кого-нибудь есть идея?

Также приветствуются любые лучшие идеи для получения журнала изменений между двумя ветвями ... Спасибо.