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

目前我们有一个标准的颠覆库布局的项目：何时应该将多模块项目拆分为单独的存储库树？

./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

的“建设”仍然是，它建立在序列中的所有模块相当铁板一块，但我初始的M怀疑，如果我们要重构建立/库的东西更像：

./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存储库本身的路径）中。

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

来源

2008-08-18 Mark Derricutt

Subversion手册包含了这两个部分：

关于这个问题的博客条目："Subversion Repository Layout"

简短的回答，虽然：当你的里程会有所不同（每种情况都是个人的），您的/bundle/<project>/(trunk|tags|branches)计划是相当普遍的，并且会很可能适合你。

来源

2008-08-18 10:45:46

这是非常可达个人喜好，但我发现下面的结构适合于由许多模块的大型项目：

 
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

我也经常使用结构中包含许多项目的大型仓库，因为将所有项目保存在同一个存储库中可以交叉参考项目并在它们之间共享代码—，并且历史记录—更容易。

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

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

来源

2008-08-18 10:27:55

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

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

来源

2008-08-20 08:13:59

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

我只是想强调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中打开bundle描述符以读取实际需要的moduleA版本。此外，如果我必须将此发行版的源代码的特定备份粘贴到CD上，我只想导出此标签而不下载数百兆字节的不相关内容。

这只是我的两美分。

来源

2009-03-04 12:04:35 Chucky

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

回答

相关问题