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

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

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

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

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

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

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