Какова хорошая структура репозитория для выпусков и проектов в Subversion?

Релизы - это то же самое, что и теги ... У вас есть несколько проектов внутри вашего багажника? В этом случае я бы скопировал те же папки внутри тегов.

Так

trunk
     fooapp
         stuff...
     barapp
         stuff...
tags
     fooapp
         1.0.0
         1.0.1
     barapp 
         1.0.0

Когда мы хотим подготовиться к выпуску, скажем, версии 3.1, мы создаем ветку branch / 3.1-Release и объединяем отдельные коммиты из основной ветки по своему усмотрению (наши ветки выпуска обычно получают только самые критические исправления из основного ветка развития).

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

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

Карл

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

В этом случае нам нужно пометить, например 1.0.0, но также и ветвь, например 1.0. Меня беспокоит смешивание веток проекта и веток выпуска, например

branches
    this-project
    that-project
    the-other-project
    1.0
    1.1
    1.2
tags
    1.0.0
    1.0.1
    1.1.0
    1.2.0
    1.2.1

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

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

project1
   trunk
   branches
     1.0
     1.1
     joes-experimental-feature-branch
   tags
     1.0.0
     1.0.1
     1.0.2
project2
   trunk
   branches
     1.0
     1.1
   tags
     1.0.0
     1.0.1
     1.0.2

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

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

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

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

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

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