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

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

• Макет Репозитория
• Планирование Организации Репозитория

Запись в блоге на эту тему: "Subversion Repository Layout"

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

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

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

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

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

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

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

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

Этот отрывок ссылается на следующую структуру : / trunk/ calc/ calendar/ spreadsheet/ … tags/ calc/ calendar/ spreadsheet/ … branches/ calc/ calendar/ spreadsheet/

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

Что касается меня, то я склонен довольно сильно соглашаться с этим и предпочитаю следующий макет: / utils/ calc/ trunk/ tags/ branches/ calendar/ trunk/ tags/ branches/ … office/ spreadsheet/ trunk/ tags/ branches/

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

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

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

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

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

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