当前，我们有一个项目，其标准的Subversion存储库布局为：

。/树干
./分支
./标签

但是，随着我们沿着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存储库本身的另一个路径)中。

一旦模块化，在项目布局上是否有准则或者"最佳实践"？

解决方案

回答

这很大程度上取决于个人喜好，但是我发现以下结构适用于包含许多模块的大型项目：

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开发并且有很多捆绑销售产品，因此它实际上更适合这里。我必须回应安德斯·桑德维格(Anders Sandvig)的评论：将主干/标签/分支保持在根级别，因为我们将只分支有限的一组模块。它也不会干扰单独构建的模块。

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

回答

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

我只想强调SVN文档中的注释(已经在另一个答案中，相同的线程中引用过)http://svnbook.red-bean.com/en/1.4/svn.reposadmin.planning.html#svn.reposadmin.projects .chooselayout

摘录引用以下结构：
/
树干/
calc /
日历/
电子表格/

标签/
calc /
日历/
电子表格/

分支机构/
calc /
日历/
电子表格/

"这种布局没有什么特别不正确的，但是对于用户而言，它可能看起来还是不那么直观。尤其是在大型，多项目的情况下，并且有很多用户，这些用户可能只熟悉其中一个或者两个项目但是，作为分支机构的兄弟姐妹倾向于不强调项目个性，而是将整个项目作为一个整体来关注。但这是一个社会问题。出于纯粹的实际原因，我们喜欢我们最初建议的安排，这很容易当有一个存储库路径保存该项目和该项目的全部历史记录，当前内容，标记的内容和分支的记录时，可以询问(或者修改或者迁移到其他地方)单个项目的全部历史记录。

就我自己而言，我倾向于对此非常赞同，并倾向于以下布局：
/
实用程序/
calc /
树干/
标签/
分支机构/
日历/
树干/
标签/
分支机构/

办公室/
电子表格/
树干/
标签/
分支机构/

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

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

而且，如果我必须将此发行版源的特定备份备份到CD上，我只想导出此标记而无需下载数百兆的无关内容。

只是我的两分钱而已。