SVN шаблон ветвления для нескольких проектов/модулей

Question

После чтения на svnbook Я пытаюсь очистить структуру моего SVN-репозитория. Chapter 4 - Branching & Merging рассказывает об использовании структуры соединительных линий, ветвей и тегов для нескольких проектов.

В моем сценарии у меня есть несколько модулей (библиотек, плагинов и вендоров), которые я поддерживаю для ряда проектов. Ни один из проектов не использует все модули, но каждый модуль используется по меньшей мере одним проектом.

1. Могу ли я создать ветвь для каждого проекта, которая ссылается на отдельные версии модулей? Похоже, что Complex Tagging является ответом на этот вопрос ...

2. Как я мог использовать Complex Tagging в качестве базовой линии для команды проекта?

3. Каким будет рабочий процесс для разработки программного обеспечения для проверки/изменения/фиксации проекта? Например, член Team Rocket хотел добавить новую функцию в плагин Fred. (см. ниже для макета)

4. Должны ли быть внесены первоначальные изменения в функциональную ветвь модуля или проекта?

В конце концов, я хотел бы видеть следующую структуру хранилища:

-Library 
| -libFoo 
| | -trunk 
| | -branch 
| | -tags 
| | 
| -libBar 
| | -trunk 
| | -branch 
| | -tags 
| | 
| -plugins 
| -pluginFred 
| | -trunk 
| | -branch 
| | -tags 
| | 
| -pluginBarney 
|  -trunk 
|  -branch 
|  -tags 
| 
-Projects 
    -Galactic 
    | -trunk 
    | -branch 
    | -tags 
    | 
    -Rocket 
    -trunk 
    -branch 
    -tags 

~ Regards

Answer 1

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

Да.

Похоже комплекса Tagging есть ответ на этот

Это может быть ответ, но из моего POV будет грязным способом. Если какой-либо из ваших проектов должен иметь как часть своего дерева какое-то известное состояниенекоторые модули также SVN-версии, я предпочту использовать SVN externals (тип каталога) с внешними источниками, сопоставленными с нужной | модуля. Это может быть пересмотр менее определение с URL для тега модуля | ветвь (не хорошо, но возможно для commitable отрасли, OK для RO тега), или PEG-revision для любого URL любого модуля

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

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

Каким будет рабочий процесс для разработки программного обеспечения для проверки/изменения/фиксации проекта? Например, член Team Rocket хотел добавить новую функцию в плагин Fred.

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

• TR Dev ветвление pluginFred, изменять, тестировать, объединить ветку в ствол pluginFred в, тест снова
• Team Rocket PM принять эти изменения и согласны использовать модифицированный pluginFred
• Внешнее определение (ы) для pluginFred в проекте Rocket Team (в какой-то ревизии) изменился с URL @ OLDREV к URL @ NEWREV (или pluginFred/**/URL1 к pluginFred/**/URL2)
• Другие команды также сообщил каким-то образом и переключатель (или нет) к новой версии

Хорошая (быстрая и пуленепробиваемая) связь в (и между) командами является самой трудной частью работы. Никакое измельчение и ПЭГ-меньше внешних для WIP - это прямой путь к хаосу и к черту разработчика

Должны ли начальные изменения выполняться на ветви функциональности модуля или проекта?

«Это зависит» ... от привычек, списки управления доступом, правила компании, разделений репозитария дерево и кросс-репозиториев проекта (для одного монолитного репо можно СВН скопировать из любого места в любое в любое время, кросс-репо переводы немного сложнее, но все же возможны). Но в целом «В чем разница?», , если у вас есть полная прослеживаемая история (и если у вас ее нет - вы должны иметь)