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

Question

В настоящее время у нас есть проект со стандартным макетом хранилища Subversion:

. / Багажник
./branches
./tags

Однако, поскольку мы движемся по пути OSGi и модульного проекта, мы получили:

. / Багажник / комплект / главный
./trunk/bundle/modulea
./trunk/bundle/moduleb ./tags/bundle/main-1.0.0
./tags/bundle/main-1.0.1
./tags/bundle/modulea-1.0.0

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

. / Комплект / главная / багажник
./bundle/main/tags/main-1.0.0
./bundle/main/tags/main-1.0.1
./bundle/modulea/trunk
./bundle/modulea/tags/modulea-1.0.0

В этом паттерне я представляю, что каждый модуль строит сам себя и сохраняет свой двоичный файл в хранилище (maven, ivy или другой путь самого хранилища Subversion).

Существуют ли руководящие указания или «передовые практики» в отношении макетов проектов, если они становятся модульными?

Answer 1

Книга Subversion содержит два раздела:

• Структура репозитория
• Планирование организации репозитория

Запись в блоге на эту тему: «Макет хранилища Subversion»

Короткий ответ, хотя: хотя ваш пробег будет варьироваться (каждая ситуация индивидуальна), ваша /bundle/<project>/(trunk|tags|branches) схема довольно распространена и, вероятно, будет работать хорошо для вас.

Answer 2

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

branches
  project-name
    module1
      branch-name
    module2   
      possibly-another-branch-name
    branch-name-on-a-higher-level-including-both-modules
      module1
      module2
tags
  ... (same as branches)
trunk
  project-name
    module1
    module2

Я также часто использовал структуру в больших репозиториях, содержащих много проектов, потому что хранение всех проектов в одном и том же репозитории облегчает создание перекрестных ссылок на проекты и совместное использование кода между ними - с историей & mdash;

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

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

Answer 3

Только мои два цента ...

Я просто хочу подчеркнуть комментарий в документации SVN (уже цитируемый в другом ответе, в той же теме) http://svnbook.red -bean.com / ru / 1.4 / svn.reposadmin.planning.html # svn.reposadmin .projects.chooselayout

Отрывок ссылается на следующую структуру: / хобот/ известково / календарь/ таблица / ... теги / известково / календарь/ таблица / ... ветви/ известково / календарь/ таблица /

"Нет ничего особенно неправильного в таком макете, но он может показаться или не казаться интуитивно понятным для ваших пользователей. Особенно в больших многопроектных ситуациях со многими пользователями, эти пользователи могут быть знакомы только с одним или двумя проектов в хранилище. Но проекты-как-ветви-братья имеют тенденцию преуменьшать индивидуальность проекта и фокусироваться на всем наборе проектов как едином объекте. Это социальный вопрос. Нам нравится наше изначально предложенное соглашение для чисто практические причины - проще задавать вопросы (или изменять, или переносить в другое место) всю историю одного проекта, когда существует единственный путь к хранилищу, содержащий всю историю - прошлую, настоящую, помеченную и разветвленную - для этого проекта и этого проекта в одиночку. "

Что касается меня, я, как правило, вполне согласен с этим и предпочитаю следующую схему: / Utils / известково / хобот/ теги / ветви/ календарь/ хобот/ теги / ветви/ ... офис / таблица / хобот/ теги / филиалы /

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

Давайте рассмотрим пример: если project-1 зависит от moduleA v1.1 и moduleB v2.3, я не хочу, чтобы более новый модуль A v2.x появлялся в тегах. На самом деле, когда я вернусь через несколько дней / недель / месяцев к этой версии с тегами, я буду вынужден открыть дескриптор пакета в теговой версии проекта-1, чтобы прочитать версию модуля А, которая действительно требуется.

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

Это были только мои два цента.

Answer 4

Я ответил на аналогичный вопрос в StackOverflow Вопрос о структуре управления версиями . Это на самом деле подходит даже лучше, так как мы занимаемся разработкой OSGi и у нас много пакетов. Я должен повторить комментарии Андерса Сандвига: держите ствол / теги / ветви на корневом уровне, поскольку вы будете разветвлять только ограниченный набор модулей. Это также не влияет на сборку модулей по отдельности.

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