Для чего вы в любом случае используете каталог svn tags?

Question

Хорошо, поэтому мы все знаем стандартную настройку SVN

trunk\
branches\
tags\

И я понимаю, что рекомендация состоит в том, чтобы в тегах были «специальные» коммиты. Однако я никогда не использовал каталог тегов и не понимаю, зачем мне это нужно.

Насколько я понимаю, теги \ будут содержать такие элементы, как "Version1Release \, Version2Release \, ThatTimeWeUpgradedEverthing \" и т. Д. , и если предполагается, что теги никогда не меняются, тогда какой смысл делать копию в системе контроля версий? Просто отметьте, что версия 712 была нашей версией 1.

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

Answer 1

Просто отметьте, что редакция 712 была нашей версией 1.

Это работает достаточно хорошо для разработчиков в команде, возможно (при условии, что у вас есть хранилище документов, чтобы делать такие заметки), но просить любого, кто не совсем близко знаком с хранилищем, "просто помнить", становится довольно неразумным довольно быстро. *

Например, скажем, ваш репозиторий доступен через сеть. Пользователь может выбрать извлечение и создание копии для своего предпочтительного, но неясного аромата * nix и захотеть получить релиз, который является парой версий назад, прежде чем вы добавите функцию, которая ему не нравится. Тэги облегчают подобные вещи.

Теги также превосходны в качестве «триггерной точки». В моих собственных репозиториях фиксация тега автоматически запускает (через ловушку post-commit) скрипт, который собирает, упаковывает и публикует его на нашем веб-сайте.

В конце концов, теги - это дешевые копии. Если вы когда-нибудь захотите «сделать снимок» вашей сборки так, чтобы это означало, что снимок никогда не изменится, отметьте его. Это не так дорого тебе. : -)

Изменить:

Рассматривать идею «реализовано как ветки» - это не так. В самом деле. На самом деле Subversion вообще не реализует ветвления или тегов. Это полностью созданные пользователем идеи, каждая из которых использует одну и ту же команду svn copy. Тем не менее, вы также используете эту команду для копирования файла в стволе; в этом нет ничего особенного. И нет ничего особенного в ветвях или тегах. Это просто обычные каталоги, которые мы решили обработать специально (и можем даже принудительно применить их через хуки), чтобы упростить администрирование проекта.

Answer 2

Просто отметьте, что редакция 712 была нашей версией 1.

Для меня создание тега означает , когда я отмечаю, что версия 712 была версией 1.

Также очень легко увидеть все сборки, этапы, выпуски и т. Д., Просто взглянув на папку Tags.

Если вы подумаете о том, как работают ярлыки в VSS, теги намного быстрее и с ними легче работать, но они выполняют то же самое. Только не переоценивайте тот факт, что это сделано с помощью команды копирования, как ветвь.

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

Answer 3

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

Как уже говорили другие теги / ветки / ствол - это всего лишь соглашение, Subversion позволяет вам копировать одну часть дерева куда-то бесплатно (почти) бесплатно, но в его ядре, вот и все.

Вы правы, что вам понадобится ветка обслуживания для вашей версии. Тег действует как ваше имя для любой конкретной версии, отправленной куда-то извне - и комментарий коммита при создании тега дает вам возможность объяснить, куда он пошел и почему (например, «публичная бета-версия», «запрос комментариев»).

Существует несколько сценариев ловушек, которые запрещают вам вносить изменения в тег, но они не будут реализованы по умолчанию, поскольку некоторые люди используют subversion совершенно другим способом (например, резервное копирование файла конфигурации и т. Д.). Subversion - это универсальный инструмент, нет «правильного» способа его использования, только строгие соглашения для обычных ситуаций.

Фактически, Collabnet начинает рассматривать, как контроль версий используется для проектов без разработки проектов . Для некоторых из них сама идея тегов ствол и ветви может быть неактуальной.

Мое соглашение, когда вы думаете о хранилище исходного кода:

• Trunk - полный список ревизий, которые могут быть выпущены для прямой трансляции
• Задача - внешнее описание задания / ошибки, которое группирует набор ревизий
• Ветка разработки - набор ревизий, которые еще не готовы к транку
• Ветка технического обслуживания - место для сбора ревизий из транка для выпуска
• Tag - именованный снимок ветки обслуживания

Теги также могут дать вам полезный URL для документации, например:

"Релиз доступен на http://svnserver/myproject/tags/1.0" Возможно: «Релиз доступен на http://svnserver/myproject/trunk@4483"

Но когда вы просматриваете хранилище, вы никогда не встретите @ 4483 и не поймете, что оно каким-то образом особенное.

Answer 4

Просто отметьте, что редакция 712 была нашей версией 1.

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

Гораздо проще просто создать тег из ревизии 712 (т.е. скопировать из r712 в каталог тегов) с именем «выпуск версии 1». И все сразу знают, что это релиз, без предварительного просмотра, какая версия была выпущена в версии 1.

Answer 5

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

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

Вы не должны извлекать тег для редактирования.

Вы не потеряете историю, переходя (копируя) в SVN. Все это связано вместе.

Answer 6

Мы использовали его для маркировки конкретных сборок, которые были интересны, но не выпускали, например: "Демонстрация инвестора" и т. Д.

Answer 7

Теги должны ссылаться на неизменяемую «версию приложения» набора файлов.
(«версия приложения», а не «внутренний технический номер версии, используемый VCS», например, ревизия для SVN, SHA-1 для Git или id для ClearCase, или ...)
Предполагается, что они служат в качестве ссылки для запроса и развертывания в другом рабочем пространстве (для тестирования или UAT - приемочные тесты -)

Поскольку SVN реализует теги как ветви: в качестве каталога, стимул для изменения файлов в теге может быть сильным, но он побьет цель тега. Другие VCS имеют понятие метки (или «базовой линии»), которая после установки больше не может быть перемещена.

На что Джордж Мауэр комментарии:

Ну, это как раз то, что я говорил. Теги никогда не следует менять, поэтому очень ... странно реализовывать их как ветви.

"реализует"? Но они не «реализовали» понятие тега. У SVN нет «тега» как такового. Они просто повторно использовали свои ветви и сказали, что они также могут быть использованы как тег.

SVN RedBook четко гласит:

Но подождите: разве эта процедура создания тега не та же самая процедура, которую мы использовали для создания ветви? Да, на самом деле, это так.
В Subversion нет разницы между тегом и веткой. Оба являются просто обычными каталогами, которые создаются путем копирования.
Как и в случае с ветвями, единственная причина, по которой скопированный каталог - это «тег», заключается в том, что люди решили обращаться с ним таким образом: пока никто не фиксирует каталог, он всегда остается снимком. Если люди начнут это делать, это станет веткой.

Answer 8

В моем опыте теги используются для маркеров релиза и там, где вы вряд ли будете вносить изменения.

Если вы создаете ветку «release2-0» и затем хотите внести изменения (например, чтобы исправить ошибку, обнаруженную после запуска), она больше не соответствует тому, что вы выпустили для версии 2.0.

Если вместо этого вы создаете тег «release2-0» и обнаруживаете, что вам необходимо исправить эту версию, вы можете создать новую ветку, исправить ее и отметить ее как «release-2-0-1».

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

Answer 9

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

Вы не хотели бы извлекать / изменять / фиксировать что-либо в каталоге тегов. Это просто место для хранения снимка вашего кода с данного момента времени.