svn - 在没有 Trunk 的情况下使用 Subversion

Question

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

还有其他人这样做吗？

如果是这样，您注意到任何优点/缺点吗？

即使您的团队没有这样做，有人对此布局有什么想法吗？

Answer 1

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

扩展我对所列问题的看法:

1)更改代码行策略:

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

• 谁可以提交代码线
• 需要多少测试(例如，单元测试必须通过吗？回归测试、完整系统测试)
• 有多少人需要进行代码审查变化
• 有哪些变化允许

通过主干方法，策略保持固定，因此更容易写下来，这使得它们更容易沟通(在更大的团队中更重要)。

例如树干:

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

版本分支:

• 唯一的维护开发人员
• 仅修复错误
• 单元测试+回归测试
• 提交前由另外 2 名开发人员进行代码审查

标记分支:

• 创建后不提交

开发者的私有(private)分支:

• 只有开发者 checkin
• 任何更改
• 仅在合并到主干之前需要进行测试
• 合并到主干之前进行代码审查

如果你有促销模型，那么你在主要开发时有一个策略，然后在准备发布时改变策略时必须告诉大家，然后在该行发布时再告诉大家另一个策略(针对代码行)。

促销模型很容易进入，它直接映射到非源代码控制的工作方式。但一旦你开始组建大型团队，就会很痛苦。

如果您查看 Linux 内核开发，您可以看到提升模型和主干模型之间的压力:Linus 的树是提升的 - 它经历合并窗口和 rc/稳定期之间的循环。但 Linux-next 和 -mm 的出现提供了更像主干的线路。

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

开源项目面临这样的问题:在从主干分支之后，它们无法强制人们完成稳定版本的苦差事。因此，推广模式更重要的是作为一种强制稳定工作的方式，而不仅仅是致力于功能。

2)搬家工作:

当开发人员正在开发一项功能时，他正在开发的代码行的策略仅更改为错误修复，他现在需要将其工作副本切换到不同的代码行。这可能很容易，也可能极其困难，具体取决于所使用的 SCM 系统。如果开发人员在主干上工作，则不会发生此问题，因为他们的工作始终会在主干上进行。如果开发人员位于私有(private)或功能分支上，那么他们的工作将只会影响主干(和版本)。

如果某个功能已 checkin ，但比当前版本延迟，您必须弄清楚如何删除它。这个问题在主干模型中仍然存在，但可能更容易解决——从主干中挑选一些东西来发布。这就是功能分支提供帮助的地方 - 但它们有集成成本。