Какова аргументация рекомендуемого макета для репозиториев Subversion?

Управление версиями с Subversion рекомендует следующий макет для (однопроектных) репозиториев (дополняется этот вопрос):

/trunk
/tags
  /rel.1 (approximately)
  ...
/branches
  /rel1fixes

Каковы относительные достоинства этой компоновки по сравнению с (возможно) более ориентированной на процесс?:

/development
  /current
  /stable
/qa (maybe)
  ...
/production
  /stable
  /Prod.2
  /Prod.1
/vendor
  /Rel.5.1
  /Rel.5.2

Обратите внимание, что я думаю о внутреннем развертывании, а не о создании продукта.

Отказ от ответственности: хотя я являюсь пользователем Subversion, мне никогда не приходилось развертывать его в реальной живой среде.

Ответ 1

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

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

С предлагаемым макетом некоторые из этих вещей менее убедительны. Является ли/развитие/стабильным ветвлением от/тока? Какая связь между/развитием/стабильной и/производственной/стабильной? Какие из этих каталогов являются тегами, и какие из них я могу проверить?

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

Ответ 2

Я попытаюсь подытожить ответы до сих пор:

Простой

"Классический" макет (ствол/+ ветки /+ теги/) имеет преимущество легкорастущей простоты
Багажник (обычно) основной линия разработки
Филиалы участвуют в специальных потребности в области развития, такие как комплексные подпроекты и пост-релиз обслуживание
Теги фиксированные, неизменяемые маркеры сообщений
Этот классический макет хорошо известен ваши разработчики получают скорость быстрее

Расширяемый

Разработка продуктов интегрированы в ваше развитие (возможно, с адаптациями) может, если требуется обрабатывать как поставщика ветки (обычно одного достаточно)
Ось "Процесс" (например, разработка, Испытание, если выполнено отдельно, QA, если используется, и Производство) можно соответствующая ветка или тег (в зависимости от того, любые изменения необходимы или разрешено за пределами "Разработка" ).
Эти дополнительные наборы ветвей может быть обработано путем именования конвенций или дополнительным уровень каталога в тегах/или ветки /.

См. другие вопросы

Я сделал это ответ сообщества; пожалуйста, не стесняйтесь исправлять или распространять любые недостатки, за которые я извиняюсь.

Ответ 3

Вы описали две довольно стандартные модели для организации репозитория: dev-test-prod и trunk-branch. Эрик Синк хорошо описывает их в своем Source HOWTO. Следует отметить, что большинство людей используют магистральную ветвь, чтобы создать ветвь для каждой версии, поскольку она выпущена для клиентов, которая затем становится ветвью обслуживания.

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

Однако одним из обстоятельств было бы то, что dev-test-prod может быть предпочтительнее в веб-разработке, где концепция версий, выпущенных для клиентов, на самом деле не существует. Prod, в данном случае, будет работать на сервере прямо сейчас, в то время как код обрабатывается в dev и тестируется и постоянно переносится в приложение, а не выпущен в один большой кусок.

Ответ 4

Я считаю, что гибкость и избежание двусмысленности - это ваш ответ.

Используя номера версий, вы не привязываетесь к развертыванию этой версии.

Например, у вас может быть версия 1.3, которая будет развернута как разработка 1.2, которая находится в тестировании и 1.1, которая находится в процессе производства. Если бы вы хотели, вы могли бы легко добавить еще одну промежуточную среду для другой версии, не изменяя свой макет subversion.

Никто не может аргументировать, какая версия 1.1 кода, но версия, устойчивая к производству, неоднозначна.

Ответ 5

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

Ответ 6

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

Ответ 7

Я думаю, что ваш план очень хорош, на самом деле. Как вы будете объяснять ветки, где программист просто блуждает? Может быть, как/development/jfm3-messing-around?