使用不带Trunk的Subversion

Question

我的团队最近决定不使用“主干”分支，这是大多数subversion存储库布局的典型。我们发现，在任何给定的时刻，总会有一个特定的分支在其他存储库中扮演主干所扮演的传统角色。也就是说，我们总是有一个编号最高的分支，代表我们正在开发的下一个版本。因此，合并到主干是多余的，所以我们去掉了主干。

外面还有其他人这样做吗？

如果是这样的话，你有没有注意到任何优点/缺点？

即使你的团队不这样做，有人对这种布局有什么想法吗？

Answer 1

你正在谈论Promotional Model -Perforce的论文强调了它的问题-沟通代码行的变化角色和在分支之间移动工作。

对我对列出的问题的看法的扩展：

1)改变代码行策略：

每一行代码都有一个策略，无论它是被写下来和正式的，还是完全隐含在开发人员的头脑中。它定义了例如：

• 谁被允许提交代码行
• 需要多少测试(例如，单元测试是否必须通过、回归测试、完整系统测试)
• 有多少人必须进行代码审查更改
• 允许什么样的更改

<代码>F210

使用主干方法，策略仍然是固定的，所以更容易写下来，这使得它们更容易沟通(在较大的团队中更重要)。

例如Trunk：

• 任何开发人员都可以提交
• 任何更改
• 单元测试必须在提交后通过
• 代码审查

版本分支：

• only maintenance developer
• only bug fix
• 单元测试+回归测试
• 代码在提交

之前由其他两个开发人员进行审查

标签分支：

• 在创建

后未提交

开发者内网分支：

• 仅开发人员签入
• 仅在合并到主干
• 之前需要的任何代码在合并到主干

之前进行代码审查

如果你有推广模型，那么你在主开发阶段就有一个策略，那么当你在准备发布的时候改变策略时，你必须告诉每个人，然后在代码行发布后告诉每个人另一个策略(针对代码行)。

推广模型是一个容易进入的模型，它直接映射到非源代码控制的工作方式。但一旦你开始组建大型团队，就会受到伤害。

如果你观察Linux内核的开发，你可以看到提升模型和Trunk模型之间的紧张关系:Linus的树是提升的-它经历了合并窗口和rc/稳定阶段之间的循环。但是Linux-next和-mm如雨后春笋般涌现出来，提供了一条更像主干的线路。

分布式SCM/VCS无论如何都有些不同，策略不必分发给所有开发人员，因为每个开发人员都有自己的树，并在他想要的时候拉出更改。

开源项目的问题在于，在从主干分支之后，它们不能强迫人们做稳定发布的苦差事。因此，推广模型更重要的是作为一种强制稳定努力的方式，而不仅仅是在功能上工作。

2)移动工作：

开发人员可能正在开发一个特性，当他正在处理的行的策略更改为错误修复时，他现在需要将他的工作副本切换到不同的代码行。根据所使用的SCM系统的不同，这可能很简单，也可能非常困难。如果开发人员在主干上工作，这个问题就不会发生，因为他们的工作总是在主干上进行。如果开发人员在私有或功能分支上，那么他们的工作只会影响到主干(和发行版)。

如果某个功能已经签入，但从它当前所在的版本延迟，你必须弄清楚如何删除它。这个问题仍然存在于主干模型中，但可能会更容易解决-从主干中挑选发布的东西。这就是功能分支发挥作用的地方--但它们有集成成本。

Answer 2

我对Perforce论文的问题是，它拒绝了促销模型，而没有提到主要优势，减少了合并开销。事实上，这篇论文错误地指出，“主线模型”强加了“没有额外的管理开销”，这是一个荒谬的说法。“总是合并到主干”模型意味着-你有每个人都必须合并的开销。如果你有以下情况(我们有)，这是没有意义的开销：

a)一个小团队(5到7个开发人员)，所有人都在彼此呼喊的距离内。当我们需要创建分支时，通信不是问题

和

b)一个代码库，其中实际上只有两个主要分支-一个生产分支和“下一个开发中的东西”。也许我们很少有三个人。

我想我的意思是--这是一种情境。说“促销模型有问题”就像说“永远不要使用OR/M”。这取决于您的环境。

Answer 3

Subversion允许这两种方法。主干不是必需品，而是一种约定。如果你有它，一些工具会更容易工作(例如Git的迁移工具)。如果你没有它，你必须手动做一些事情，但我想不出你在日常工作中会注意到什么。