Вопрос по svn – В чем причина рекомендуемого макета для хранилищ Subversion?

17

Version Control with Subversion рекомендует следующий макет для репозиториев (с одним проектом) (дополненныйthis question):

/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, мне никогда не приходилось развертывать его в реальной среде.

Ваш Ответ

7   ответов
0

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

Благодарю. В этом есть смысл; но он сам по себе не является разумным основанием для первого стандартного макета, что на самом деле я и пытаюсь исследовать здесь. Brent.Longborough
9

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


Simple

  1. The "classic" layout (trunk/ + branches/ + tags/) has the advantage of growable simplicity
  2. The Trunk is (usually) the main development line
  3. Branches attend to special development needs such as complex subprojects and post-release maintenance
  4. Tags are fixed, immutable marker posts
  5. This classic layout is well-known so your developers get up to speed faster

Expandable

  1. Vendor development of products integrated into your development (perhaps with adaptations) can, if required be handled as a vendor branch (normally one is enough)
  2. The "Process" axis (Eg. Development, Test if done separately, QA if used, and Production) can be handled by appropriate branch or tag conventions (depending on whether any changes are required or permitted outside "Development").
  3. These additional sets of branches can be handled by naming conventions, or by an additional directory level within tags/ or branches/.

See Other Questions

  1. What does branch, tag and trunk really mean?
  2. What is a good repository layout for releases and projects in Subversion?
  3. Do you use the branches-tags-trunk convention?

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

18

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

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

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

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

Спасибо. Мне особенно нравится ваше наблюдение, что «стабильный» неоднозначно. Здесь настоящая пища для размышлений. Brent.Longborough
Поскольку очень важно, чтобы в команде все правильно выполняли компоновку, стандартная компоновка SVN оставляет мало двусмысленности, когда разработчик понимает заголовок, ветвление и тегирование.
-1

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

Да, это была бы идея Brent.Longborough
5

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

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

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

Спасибо за действительно хорошую ссылку. Brent.Longborough
0

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

Да, спасибо, я начинаю подозревать, что мне нужны теги стволовых веток в каждом из моих каталогов верхнего уровня. Brent.Longborough
2

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

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

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

Никто не может поспорить, что такое версия 1.1 кода, но «стабильно работоспособен» версия неоднозначна.

Спасибо. Мне действительно нужно переосмыслить «стабильный». Brent.Longborough

Похожие вопросы