应该将多模块项目何时拆分为单独的存储库树？

目前我们有一个标准的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存储库本身的另一个路径)中.

一旦模块化,是否有关于项目布局的指导方针或"最佳实践"？

Subversion书包含两个部分:

存储库布局

规划您的存储库组织

关于这个主题的博客文章:"Subversion Repository Layout"

但简短的回答是:虽然你的里程会有所不同(每种情况都是个人的),但你的/bundle//(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

我还经常在包含许多项目的大型存储库中使用该结构,因为将所有项目保存在同一个存储库中会使交叉引用项目和它们之间共享代码 - 更容易使用历史记录.

我喜欢从一开始就使用根干,标签和分支文件夹的结构,因为根据我的经验(包含许多项目的大型存储库),许多子项目和模块永远不会有单独的标签或分支,所以没有必要为它们创建文件夹结构.它还使开发人员更容易检查存储库的整个主干,而不是获取所有标签和分支(他们大多数时间不需要).

我想这是项目或公司政策的问题.如果每个项目都有一个存储库,或者给定的开发人员只能在存储库中的单个项目上工作,那么有根的主干可能没有多大意义.