TFS: метки против наборов изменений

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

спасибо!

31
changeset label tfs

4 ответов

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

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

32

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

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

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

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

7

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

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

Changeset
Date
Label
Latest Version
Workspace Version

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

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

2

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

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

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

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

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

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

0