Что такое хороший репозиторий для релизов и проектов в Subversion?

Question

У нас есть стандартный макет Subversion trunk/branch/tags. У нас есть несколько филиалов для среднесрочных и долгосрочных проектов, но пока нет релиза. Это приближается быстро.

мы должны:

1. релиз Mix филиалы и отделения проекта вместе?
2. Создайте папку с папками? Если да, то есть ли лучшее имя, чем релизы?
3. Создайте папку проектов и переместите туда текущие ветви? Если да, то лучше ли название, чем проекты? Я видел «песочницу» и «всплеск» в других репозиториях.
4. Что-то еще?

Answer 1

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

Так

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

Answer 2

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

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

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

Карлы

Answer 3

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

В этом случае мы должны пометить, например. 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 

Answer 4

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

И кстати: Это хорошая идея с несколькими хранилищами, а не много, потому что история изменений обычно лучше сохраняется, что путь (история изменений исчезнет, ​​если вы перемещаете файлы между репозиториями, если только не выполняете специальное и несколько сложное действие). В большинстве установок должны быть только два репозитория: главный репозиторий и хранилище песочниц для людей, экспериментирующих с 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 

Answer 5

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

Answer 6

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

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

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

Answer 7

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

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