Я думаю, что это то, что вы хотите использовать. Хотя набор изменений идентифицирует определенный набор изменений кода, когда вы выполняете операции в TFS на основе набора изменений, TFS обычно интерпретирует его как «все изменения вплоть до и включая набор изменений XXX».
Итак, предположим, вы просите разветвить на changeet 12345. TFS получит все файлы, связанные с набором изменений меньше или равным 12345 - даже если они не являются частью 12345.
Другой вариант, который вы можете сделать, - это ветвь, основанная на конкретной дате/времени. Например, если у вас был основной релиз 1 июня в 11:00, вы можете просто вывести весь код с этой конкретной даты и времени.
Все, что сказано, в нашей организации мы используем этикетки. Да, ярлыки можно перемещать, но это не обязательно плохо, поскольку это позволяет вам учитывать ошибки. Например, допустим, у нас есть ярлык: ProdMove_June.
Спустя некоторое время после июньского выпуска мы понимаем, что из-за отказа процесса файл конфигурации не был включен в TFS (или файл был развернут из TFS, но его необходимо было изменить за пределами процесса SCM, чтобы реагировать на чрезвычайную ситуацию). Затем мы переносим этот файл в TFS и должны маркировать его для всех будущих ветвлений. Если это так, то все, что нам нужно сделать, это переместить ярлык в этот единственный файл.
На мой взгляд, все три из этих подходов действительны, и мы фактически используем все три в нашей организации для построения, ветвления и получения кода. Я предлагаю вам вооружить себя всеми тремя из них на вашем поясе и использовать их там, где это необходимо.