В чем причина рекомендуемой компоновки репозиториев Subversion?

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

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

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

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

Попробую пока суммировать ответы:

Простой

1. "Классический" макет (trunk / + branch / + tags /) имеет преимущество в простоте расширения.
2. Ствол (обычно) является основным направлением разработки.
3. Филиалы занимаются особыми потребностями в разработке, такими как сложные подпроекты и пост-релизное обслуживание.
4. Теги фиксированные, неизменяемые маркерные сообщения
5. Этот классический макет хорошо известен, поэтому ваши разработчики быстрее освоятся.

Расширяемый

1. Разработка продуктов, интегрированных в вашу разработку (возможно, с адаптациями), может, при необходимости, осуществляться как ветвь поставщика (обычно достаточно одного).
2. Ось «Процесс» (например, «Разработка», «Тестирование», если выполняется отдельно, «Контроль качества, если используется» и «Производство») может обрабатываться соответствующими соглашениями о ветвях или тегах (в зависимости от того, требуются ли какие-либо изменения вне «Разработка»).
3. Эти дополнительные наборы ветвей могут обрабатываться соглашениями об именах или дополнительным уровнем каталогов внутри тегов / или branch /.

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

1. Что на самом деле означают ветвь, тег и ствол?
2. Какова хорошая компоновка репозитория для выпусков и проекты в Subversion?
3. Используете ли вы соглашение «ветки-теги-ствол»?

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

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

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

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

Думаю, ваш ответ - гибкость и недопущение двусмысленности.

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

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

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

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

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

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