Лучшая практика для тегов SVN?

Ответ 1

Не забывайте, что тег и ветвь по сути являются тем же самым в SVN: оба являются результатом svn copy

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

То, что представляет этот снимок (тег), полностью зависит от вас. это может быть:

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

Ответ 2

Не уверен, что вы подразумеваете под "отдельными версиями", но мы копируем из соединительной линии или ветки, которую мы создаем в папку тегов с описательным именем, например Proj-1.20.33

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

Книга SVN рассказывает об этом немного в Общие шаблоны ветвления и Tags.

Ответ 3

Большинство людей, которых я знаю, все еще на SVN-теге их сундук (или текущая производственная ветвь) перед каждой версией.

Ответ 4

Я предпочитаю следующее структурирование каталога репозитория моих тегов:

/tags
    /builds
        /PA
        /A
        /B
    /releases
        /AR
        /BR
        /RC
        /ST

PA означает pre-alpha A означает alpha B означает beta​​strong > AR означает альфа-релиз BR означает бета-релиз RC означает кандидат на выпуск ST означает стабильный

Существуют различия между сборками и выпусками.

• Теги в папке builds имеют номер версии, соответствующий шаблону N.x.K, где N и K являются целыми числами. Примеры: 1.x.0, 5.x.1, 10.x.33
• Теги в папке выпуска содержат номер версии, соответствующий шаблону N.M.K, где N, M и K являются целыми числами. Примеры: 1.0.0, 5.3.1, 10.22.33.

Пример результирующей структуры каталога репозитория tags в определенный момент времени при эволюции структуры репозитория будет следующим:

/tags
    /builds
        /PA
            /1.x.0
            /1.x.1
        /A
            /1.x.2
        /B
            /1.x.3
            /1.x.4
    /releases
        /AR
            /1.0.0
            /1.1.0
        /BR
            /1.0.1
            /1.0.2
            /1.1.1
        /RC
            /1.0.3
            /1.1.2
        /ST
            /1.0.4
            /1.1.3

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