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

Question

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

./багажник
./филиалы
./теги

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

./магистраль/комплект/главная
./магистраль/комплект/модуль
./магистраль/связка/модуль ./теги/связка/главная-1.0.0
./теги/связка/главная-1.0.1
./теги/комплект/модуль-1.0.0

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

./комплект/основной/магистральный
./bundle/main/теги/main-1.0.0
./bundle/main/теги/main-1.0.1
./комплект/модуль/магистраль
./bundle/modulea/теги/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

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

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

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

Answer 3

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

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

В выдержке содержится ссылка на следующую структуру :/ магистраль/ вычисление/ Календарь/ электронная таблица/ … Теги/ вычислять/ Календарь/ электронная таблица/ … ветви/ calc/ Календарь/ электронная таблица/

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

Что касается меня лично, то я склонен полностью согласиться с этим и предпочитаю следующий макет:/ утилиты/ calc/ магистраль/ Теги/ ветви/ Календарь/ багажник/ Теги/ ветви/ … Офис/ электронная таблица/ магистраль/ Теги/ ветви/

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

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

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

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

Answer 4

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

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