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

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

12 голосов
/ 16 декабря 2008

Должен ли я использовать их как отдельные выпуски? Я проверяю их обратно в ствол или ветви? Это все в красной книге, а я просто потратил впустую ваше время?

Ответы [ 4 ]

16 голосов
/ 16 декабря 2008

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

Хитрость в том, что, поскольку тег представляет собой моментальный снимок, он должен быть «неизменяемым», поскольку в него не следует вносить какие-либо изменения.

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

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

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

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

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

6 голосов
/ 16 декабря 2008

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

2 голосов
/ 12 января 2012

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

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

PA означает пре-альфа A означает альфа B означает бета AR означает альфа-релиз BR означает бета-релиз RC означает кандидат на освобождение ST означает стабильный

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

  • Теги в папке builds имеют номер версии, соответствующий шаблону N.x.K, где N и K - целые числа. Примеры: 1.x.0, 5.x.1, 10.x.33
  • Теги в папке release имеют номер версии, соответствующий шаблону 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

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

...