Должен ли я создать папку для веток релиза в SVN?

Question

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

\trunk
\branches
    \feature-a
    \feature-b
    \...
\tags
    \1.0 
    \...

Я понимаю, что svn - это то, что папки trunk / branch / tags не имеют особого значения для svn. Буду ли я сталкиваться с какими-либо проблемами, добавляя папку релизов в корень проекта и помещая все мои ветки релизов в эту папку?

\trunk
\branches
    \feature-a
    \feature-b
    \...
\releases
    \release-a
    \...
\tags
    \1.0 
    \...

Создание новой ветки релиза будет выглядеть так:

svn copy http://project/trunk http://project/releases/release-b

Answer 1

Как вы структурируете свой репозиторий, зависит от вас. Если вам нужны ветки категорий / папок / и т.д., пусть будет так. Как только вы определитесь со структурой, которая вам нужна / нужна, вы создадите процесс для ее обработки. Основные команды Subversion, конечно, не изменятся.

Answer 2

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

Мое предложениебудет просто переименовать папку «теги» в «релизы».

Answer 3

Было бы хорошо, хотя лично мне это не очень нравится.«Релизы» звучат как своего рода тег (фиксированная точка), когда вы подразумеваете, что это своего рода ветвь (эволюционирующая к релизу.)

Answer 4

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

В некоторых проектах я использую отдельный репозиторий для релизов и svn: external в качестве хэнда.в этом смысле это скорее передача «сдачи» другой группе.рабочие процессы разработки и развертывания операций могут отличаться.это разделило два.

на проект, который я сейчас настраиваю - вероятно, назову его maint или support, чтобы оживить ситуацию:)