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

В настоящее время у нас есть проект со стандартной версией репозитория subversion:

./trunk
./branches
./tags

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

./trunk/bundle/main
./trunk/bundle/modulea
./trunk/bundle/moduleb ./tags/bundle/main-1.0.0
./tags/bundle/main-1.0.1
./tags/bundle/modulea -1.0.0

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

./bundle/main/trunk
./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).

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

18.08.2008 09:51:18
4 ОТВЕТА
РЕШЕНИЕ

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

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

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

7
26.11.2013 04:29:07

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

ветви
  название проекта
    module1
      филиал имя
    module2   
      возможно, другой Гиса имя
    Имя филиала-на-а-выше уровня, в том числе-как-модулей
      module1
      module2
теги
  ... (так же, как ветви)
хобот
  название проекта
    module1
    module2

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

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

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

6
18.08.2008 10:27:55

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

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

0
23.05.2017 12:13:37

Просто мои два цента ...

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

Отрывок ссылается на следующую структуру: / багажник / кальций / календарь / электронная таблица /… теги / кальций / календарь / электронная таблица /… ветви / кальций / календарь / электронная таблица /

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

Что касается меня, я, как правило, вполне согласен с этим и предпочитаю следующую раскладку: / utils / calc / trunk / tags / филиалы / календарь / trunk / tags / branch /… офис / электронная таблица / trunk / tags / ветки /

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

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

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

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

3
4.03.2009 12:04:35