使用没有主干的 Subversion答案

【问题标题】：Use Subversion Without Trunk使用没有主干的 Subversion
【发布时间】：2010-11-22 07:46:08
【问题描述】：

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

还有其他人这样做吗？

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

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

【问题讨论】：

标签： svn branch trunk

【解决方案1】：

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

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

1) 更改代码行策略：

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

允许谁提交代码行
需要多少测试（例如，单元测试是否必须通过，回归测试、完整系统测试）
需要多少人进行代码审查变化
有哪些变化允许

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

例如后备箱：

任何开发者都可以提交
任何变化
单元测试必须通过
提交后的代码审查

版本分支：

仅限维护开发人员
仅修复错误
单元测试 + 回归测试
提交前由其他 2 位开发人员进行代码审查

标签分支：

创建后无提交

开发者的私有分支：

只有开发者才能签到
任何更改
只需要在合并到主干之前进行测试
合并到主干之前的代码审查

如果你有推广模式，那么你在主开发时有一个策略，然后在准备发布时更改策略时必须告诉所有人，然后在行发布后另一个策略（用于代码行）。

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

如果您查看 Linux 内核开发，您会发现 Promotional 模型和 Trunk 模型之间的紧张关系：Linus 的树是 Promotional 的 - 它在合并窗口和 rc/stabilisation 周期之间经历循环。但是 Linux-next 和 -mm 已经出现，以提供更像主干的线路。

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

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

2) 搬家工作：

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

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

【讨论】：

道格拉斯，您能在回答中详细说明这一点吗？ “促销计划有两个严重的缺点：（1）它需要改变代码线的政策，这很难与每个人沟通；（2）它需要开发人员将他们正在进行的工作重新定位到另一个代码线，这是容易出错且耗时。90% 的 SCM“流程”都在执行代码线提升以弥补主线的不足。”
@RichardOD 你知道我在哪里可以找到这篇文章吗？
@MrPhi 旧链接似乎已失效。 info.perforce.com/high-level-best-practice-SCM-WP-reg.html 有效，但需要输入一些信息。

【解决方案2】：

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

a) 一个小团队（5 到 7 名开发人员），彼此都在喊叫距离之内。当我们需要建立一个分支时，沟通不是问题

和

b) 一个代码库，其中实际上只有 2 个主要分支 - 一个生产分支和“开发中的下一个分支”。也许千载难逢，我们有 3 个。

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

【讨论】：

是的 - 我同意 - 在小型团队中，沟通的开销较低，并且稳定发布所需的工作无论如何都涉及到每个人（因此主干要么稳定（只有错误修复），要么停滞不前（错误修复在不同的分支））
根据我的经验，移动工作开销仍然会发生。
我发现它很有用 - 如果在稳定过程中错误级别不高，那么即使它们已被排除在发布版本之外，也有地方进行错误修复。

【解决方案3】：

IME，在某些环境中，主干是交换修复和更改的好地方。也就是说，每个人都将他们的修复合并到主干，每个人都将其他人的修复从主干合并。我们发现这在许多独立项目之间共享大量代码并且所有这些项目都为共享代码做出贡献的环境中非常有用。

不过，您的环境可能会有所不同。

【讨论】：

【解决方案4】：

我最近开始研究一个位于 subversion 存储库上的项目。创建存储库的人并没有遵循任何特定的布局——他们只是将所有内容都塞进了存储库的根目录（没有主干/，没有分支/，当然也没有标签/）。我想为其他东西创建一个分支和一些标签，但我意识到在不遵循正确布局的 subversion 存储库上这样做是多么困难。

【讨论】：

这当然是真的 - 我很确定在这种情况下它是一个稻草人，但提问者已经有多个分支。

【解决方案5】：

我们确实 - 有点。我们不使用主干，而是为项目的每个版本创建一个新分支。这个“标记”的分支是每个版本的主干，我们通过将更改合并到旧版本来支持错误修复。

它对我们很有效，但我们的项目中确实有很多子项目。

【讨论】：

【解决方案6】：

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

【讨论】：