Сначала вопрос, а затем немного фона.
Мы используем Visual Studio 2008, C # 3.0 и .NET 3.5 и TFS 2008 в качестве нашей VCS.
Если я выполню эту командудля нашей базы данных TFS, чтобы показать информацию о коммите слияния:
tf changeset 13469 /noprompt
Я получаю вывод, подобный этому (отредактированный):
Changeset: 13469
User: Lasse
Date: 12. november 2010 14:06:06
Comment:
Some text here.
Items:
merge, edit $/path/to/target/filename.txt
... more merged files
... some blurb about reviewer texts, etc. nothing important/useful here
Это было объединено с другого пути в том жебазы данных, но эта информация здесь недоступна.
Например, если я произвел слияние с $/path/to/main/ до $/path/to/branch/, путь к основному проекту не будет доступен в наборе изменений слияния. (заметьте, пожалуйста, не говорите, что я объединяюсь не так, в данном случае это не имеет значения, поэтому я просто упростил это.)
Итак, вопросэто: есть ли какой-нибудь способ, чтобы я мог узнать, откуда этот набор изменений был объединен?Из какой это ветки?... и , чей набор изменений произошел, как в этой ветви (например, 13468? 13462? 13453? ...)
Фон
До сих пор мы не использовали много разветвлений и слияний, за исключением таких простых вещей, как «пометка» релиза.
Отныне мы рассматриваем использование разветвлений гораздо более активно, но это создает проблему..
Допустим, я открываю наш баг-трекер, беру самую верхнюю ошибку, исправляю ее и проверяю ее. Это делается в одной ветви, скажем, это основная ветвь.
Теперь, в какой-то момент, тестер собирается проверить, что исправление, которое мы собираемся выпустить, исправило эту ошибку, поэтому он открывает наш продукт и хочет проверить, прежде чем он начнет, что исправление действительно вошло в эту сборку.
Когда мы не использовали ветвление, мы просто взяли номер набора изменений коммита, который в итоге зафиксировал случай, и ввели его в самом случае.Кроме того, наш продукт был построен с номером сборки (четвертая часть номера версии), идентичным номеру ревизии, которая была последней версией ревизии, которая стала частью сборки.
Таким образом, тестер мог просто посмотреть наВ этом случае номер версии и легко определить, имел ли этот набор изменений этот набор или нет.Если номер набора изменений в номере версии был больше или равен номеру в данном случае, набор изменений был частью этой сборки.
С ветвями это не работает.Если я фиксирую набор изменений X в основной ветке, но забываю объединить, тестировщик не может просто сказать «Если я запускаю версию X или выше, я исправлю это» больше.
Обратите внимание, что мыя не использую рабочие элементы TFS, поэтому нет простого встроенного способа связать коммиты и случаи.
Причина, по которой я спросил о выводе истории TFS, заключалась в том, что я предполагаю, что если я увижу, что набор изменений 13469 действительно произошелдругая ветвь, и соответствует там 14462 ревизии, и программист отметил 13462 для случая, я могу сказать, что «13462 теперь является частью сборки, потому что она была объединена с правой веткой, стала 13469, и выходные данные сборки имеют версию13470. "
Другими словами, я мог бы создать инструмент, который в рамках сборки смотрел на историю базы данных, собирал всю необходимую информацию и сохранял ее в базе данных, чтобы я мог принимать кейсыв нашем списке готовых к тестированию и сравните с номером версии исполняемого файла, на котором работал тестер, и просто перечислите все случаи, которые одновременноготов к тестированию и части этой сборки.
Так что мой вопрос действительно такой: есть ли у кого-нибудь какие-либо намеки на то, как мы можем решить эту проблему?Возможно, у нас тупая голова, и нам нужно правильно сказать, как это сделать, поэтому, если у вас появятся хорошие идеи, дайте мне знать.