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

Question

目前我们有一个标准的subversion存储库布局项目：

./躯干
./branches
./tags

然而，当我们沿着OSGi和模块化项目的道路前进时，我们最终得到了：

./躯干/束/主
./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/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存储库本身的另一个路径）中。

一旦模块化，项目布局是否有指导方针或“最佳实践”？

Answer 1

Subversion书包含两个部分：

• Repository Layout
• Planning Your Repository Organization

关于此主题的博客文章："Subversion Repository Layout"

简短的回答是：虽然您的里程会有所不同（每种情况都是个人的），但您的/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

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

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

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

Answer 3

只是我的两分钱......

我只想强调SVN文档中的评论（已经引用另一个答案，同一个帖子）http://svnbook.red-bean.com/en/1.4/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout

摘录参考以下结构： /    树干/       钙/       日历/       电子表格/       ...    标签/       钙/       日历/       电子表格/       ...    分支机构/       钙/       日历/       电子表格/

“对于这样的布局没有什么特别不正确的地方，但对于您的用户来说，这可能是也可能不那么直观。特别是在有大量用户的大型多项目情况下，这些用户可能只熟悉一两个用户但是作为分支兄弟姐妹的项目往往不再强调项目的个性，而是将整个项目集中在一个单一的实体上。这是一个社会问题。我们最喜欢我们原先建议的纯粹安排实际原因 - 当单个存储库路径包含该项目和该项目的整个历史记录 - 过去，现在，标记和分支时，更容易询问（或修改或迁移到其他地方）单个项目的整个历史记录单独“。

对于我自己，我倾向于非常同意这一点，并且更喜欢以下布局： /    utils的/       钙/          树干/          标签/          分支机构/       日历/          树干/          标签/          分支机构/       ...    办公室/       电子表格/          树干/          标签/          分支机构/

原因很简单，当人们想要只标记一个特定的子集时，标记一个完整的项目集是不切实际的。

让我们举个例子：如果project-1依赖于moduleA v1.1和moduleB v2.3，我不希望更新的moduleA v2.x出现在标签中。实际上，当在某些日/周/月后回到此标记版本时，我将被迫在标记版本的project-1中打开包描述符，以读取实际需要的moduleA版本。

此外，如果我必须在CD上对此版本的源进行特定备份，我只想导出此标记而不下载数百兆字节的无关内容。

这只是我的两分钱。

Answer 4

我在StackOverflow Version Control Structure question中回答了类似的问题。它实际上在这里更合适，因为我们做了大量的OSGi开发并且有很多捆绑。我必须回应Anders Sandvig的评论：将trunk / tags / branches保留在根级别，因为你只会分支一组有限的模块。它也不会干扰单独构建的模块。

我不会复制我之前的答案，但这与这个问题完全相关。