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

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

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

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

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

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

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

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

Запись в блоге на тему: «Схема репозитория Subversion»

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

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

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

Всего два цента ...

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

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

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

Лично я склонен полностью согласиться с этим и предпочитаю следующий макет: / utils / calc / хобот/ теги / ветви/ календарь/ хобот/ теги / ветви/ … офис/ электронная таблица / хобот/ теги / ветви/

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

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

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

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