Сначала вопрос, затем некоторый фон.Как интерпретировать информацию о слиянии в выходном файле журнала TFS (или: как узнать, какие изменения являются частью сборки?)
Мы используем 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? ...)
фон
Мы не использовали много ветвления и слияния так далеко, за исключением простых вещей, таких как «маркировка» релиза.
Отныне мы рассматриваем возможность использования ветвления гораздо более активно, но это создает проблему.
Скажем, я открываю наш трекер ошибок, беру верхнюю ошибку, исправляет ее и проверяет. Это делается в одной ветви, допустим, это главная ветвь.
Теперь, в какой-то момент, тестировщик проверяет, исправлена ли ошибка исправления, поэтому он открывает наш продукт и хочет проверить, прежде чем он начнет, что исправление действительно перешло в эта сборка.
Когда мы не использовали ветвление, мы просто взяли номер набора изменений, который в конечном итоге зафиксировал случай и набрал его в самом случае. Кроме того, наш продукт был построен с номером сборки (4-я часть номера версии), идентичным набору изменений, который был последним набором изменений, который стал частью сборки.
Таким образом, тестер может просто взглянуть на корпус, номер версии и легко вывести, если сборка имела этот набор изменений или нет. Если номер набора изменений в номере версии был равен или больше, чем номер в этом случае, набор изменений был частью этой сборки.
С ветками это не работает. Если я фиксирую набор изменений X на главной ветке, но забываю слить, тестер не может просто сказать «Если я запустил версию X или выше, я пойду это исправление».
Обратите внимание, что мы не используем рабочие элементы TFS, поэтому нет простого встроенного способа связывания фиксаций и случаев.
Причина, по которой я спросил о выходе истории TFS, состояла в том, что я предполагаю, что если я увижу, что набор изменений 13469 действительно пришел из другой ветви и соответствует списку изменений 13462, а программист отметил 13462 в этом случае, я могу «13462 теперь является частью сборки, потому что она была объединена с правой ветвью, стала 13469, а выход сборки имеет версию 13470».
Другими словами, я мог бы создать инструмент, который как часть сборки рассмотрел историю базы данных и захватил всю необходимую информацию и сохранил ее в базе данных, чтобы я мог принимать дела на наших готовых -test list и сравнить с номером версии исполняемого файла, который тестировал тестер, и просто перечислить все случаи, которые готовы к тестированию и часть этой сборки.
Итак, мой вопрос действительно в этом: есть ли какие-либо намеки на то, как мы можем это решить? Возможно, мы пронзительны, и нам нужно сказать правильный путь, чтобы сделать это, поэтому, если у вас есть хорошие идеи, дайте мне знать.
Программист, выполняющий слияние, отмечает также набор изменений слияния на корпусе. Это было лучшее, что мы могли бы придумать. –