Подтвердить что ты не робот

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

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

Спасибо!

4b9b3361

Ответ 1

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

Changeset
Date
Label
Latest Version
Workspace Version

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

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

Ответ 4

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

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

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

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

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

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