Для чего Вы используете каталог тегов svn так или иначе?

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

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

] Также очень легко увидеть все сборки, вехи, выпуски и т. Д., Просто посмотрев на папку «Теги».

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

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

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

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

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

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

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

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

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

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

Мое соглашение, когда я думаю о репозитории исходного кода:

• Trunk - полный список ревизий, которые могут быть выпущены для работы
• Задача - внешнее описание задания / ошибки, которое группирует набор ревизий
• Ветвь разработки - набор ревизий, которые не ' Возможно: «Релиз доступен по адресу http: // svnserver / myproject / trunk @ 4483 »

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

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

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

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

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

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

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

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

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

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

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

SVN RedBook четко заявляет:

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

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

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

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

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

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

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