TFS: ярлыки против изменений

Question

Я пытаюсь придумать лучшие практики использования контроля версий TFS. Прямо сейчас, каждый раз, когда мы делаем сборку, мы помечаем файлы, которые проверяются в TFS, номером версии. Является ли этот подход лучше или хуже, чем просто проверка файлов и наличие номера версии в комментариях? Можете ли вы затем использовать набор изменений, чтобы вернуться в случае необходимости, или ярлыки все еще более универсальны?

Спасибо!

Answer 1

У них две разные цели, ChangeSets - это когда файлы фактически изменились, и вы хотите сохранить постоянную запись об этом изменении. Метки обозначают определенную версию файлов, чтобы вы могли легко вернуться к этой точке. Если ваша сборка фактически не изменяет файлы под управлением исходного кода, и вы хотите записать эти изменения. Вы должны маркировать.

Кроме того, маркировка намного менее ресурсоемка. И вы можете иметь несколько меток в одной и той же версии файла.

Answer 2

Вы должны пометить версии исходных файлов, которые составляют вашу сборку. Если вы используете TeamBuild, он делает это автоматически. Он объединяет имя вашего определения сборки, дату и номер сборки. Так что вам не нужно ничего делать.

Ваш другой вариант не очень обычен и требует много ненужной работы. Если я правильно понимаю, вы бы проверили свои исходные файлы во время процесса сборки, а затем вернули их обратно с номером версии, указанным в комментариях к регистрации. Алекс отметил, что это очень ресурсоемкий процесс сборки и управления исходным кодом. Кроме того, как бы вы получили исходные файлы для конкретной версии, если информация о версии встроена в комментарии? Это будет очень сложно, и вам придется сесть и написать свое собственное приложение, которое использует API управления исходным кодом TFS для загрузки исходных файлов в рабочее пространство путем поиска номера версии в комментариях регистрации. Это создает ненужные сложности и головные боли.

Если вместо этого вы используете метки, вы можете выполнить процедуру get by label в VS IDE, чтобы загрузить исходные файлы, которые составляют эту метку. Вы даже можете сказать TeamBuild использовать метку вместо загрузки последних исходных файлов во время автоматизации сборки. Таким образом, вы можете легко создавать предыдущие версии вашего приложения. С помощью ярлыков вы также можете применить более поздние наборы изменений к существующему ярлыку, если были изменения в коде, просто получив этот ярлык и затем получив конкретные наборы изменений, а затем выполнив быструю метку или создав новый ярлык.

Маркировка очень мощная, удобная в использовании и является частью TFS. Вместо того, чтобы придумывать свое собственное решение, которое требует много усилий, чтобы оно работало и поддерживало, просто попробуйте использовать то, что уже доступно.

Answer 3

Прямо сейчас, каждый раз, когда мы делаем сборку, мы помечаем файлы, которые проверяются в TFS, номером версии

Тебе не нужно это делать. TFS может ссылаться на состояние кодовой базы множеством способов, из которых метки действительно являются одними, но также как и сборки и даже наборы изменений. Вы можете увидеть доступные способы восстановления определенного момента времени, выполнив Get Specific Version... и изучив параметры в раскрывающемся списке Type:

Changeset
Date
Label
Latest Version
Workspace Version

Changeset позволяет получить сразу после любой ревизии; Date очевидно; Label тоже, за исключением того, что автоматически строит * создает метки (выберите Label из этого выпадающего списка, затем посмотрите в диалоге Find Label).

* Я думаю, что это автоматически! Если это не то, что мы настроили специально там, где я сейчас нахожусь ...

Answer 4

StackOverflow не позволяет мне комментировать ответы выше, поэтому я пишу это как новый «ответ». Я хочу уточнить некоторые из заблуждений, перечисленных выше.

Во-первых, использование меток TFVC требует больше ресурсов, чем использование наборов изменений. Намного больше. Такие команды, как Branch, Merge и Get by Label, работают медленнее. Для корпоративных серверов с огромными базами данных вы не хотите использовать метки.

Во-вторых, сборки не создают автоматически метки, хотя стандартные шаги сборки включают шаг для создания метки.

В-третьих, как уже упоминалось, метки можно перемещать или удалять, поэтому они гораздо менее надежны, чем наборы изменений, которые являются неизменными.

В целом, я рекомендую НЕ использовать этикетки. Самая простая альтернатива - просто запомнить номер набора изменений для ваших сборок. Или, если вы хотите изолировать разные версии релизов, вы должны создать ветки релизов.

Метки подходят для небольших систем, но не подходят для крупных предприятий.