我的团队最近决定不使用大多数Subversion版本库布局的典型“trunk”分支。我们发现在任何特定时刻，总是有一个特定的分支在传统角色中起作用，即树干可能在其他存储库中存在。也就是说，我们总是拥有最高编号的分支，代表我们正在开发的下一个版本。因此合并为主干简直是多余的，所以我们摆脱了主干。使用Subversion Without Trunk
有没有其他人在那里做这个？
如果是这样，你有没有注意到任何优点/缺点？
即使你的团队没有这样做，有没有人对此布局有任何想法？
你在说的是Promotional Model - Perforce的论文强调了它的问题 - 沟通代码行的变化角色并在分支之间移动工作。
对我的看法的问题的扩展所列：
每一行代码有一个政策，无论是写下来，形式化，或在完全隐：
1）的代码行更改政策开发人员的头。它定义例如：
使用中继方式，策略保持不变，所以更易于记录，这使得它们更易于沟通（在更大的团队中更重要）。
例如干线：
版本分支：
标签分支：
开发者的私有承诺分支：
之前，如果您有推广模式需要合并之前开发的检查，那么你有一个策略而在主要开发中，则必须在准备发布时告诉所有人何时更改策略，然后在发布该线路时再告知其他策略（对于代码行）。
促销模式很容易进入，它直接映射到非源代码控制的工作方式。但是一旦你开始成为大型团队，它会很痛苦。
如果您看看Linux内核开发，您可以看到促销模型和Trunk模型之间的紧张关系：Linus的树是Promotional - 它经历合并窗口和rc /稳定期之间的循环。但是，Linux-next和-mm已经出现，可以提供更多类似主干的线路。
分布式SCM/VCS是有所不同的，无论如何，政策没有分发给所有的开发人员，因为每个开发有自己的树木，而当他想拉变化。
开源项目遭受的问题是，他们不能强迫人们在干线分支之后做稳定版本的苦差事。因此，促销模式作为强制稳定工作的一种方式更为重要，而不仅仅是针对功能。
2）移动工作：
开发人员可以在一个功能一起工作时，他的工作对更改错误修复行政策只是，他现在需要他的工作副本切换到不同的代码 - 线。 根据所使用的SCM系统，这可能从简单到极端困难。 如果开发人员在主干上工作，则不会发生此问题，因为他们的工作总是要中继。如果开发人员在私人或功能分支上，那么他们的工作只会影响主干（和发布）。
如果某个功能已经签入，但会从当前版本延迟，您必须制定如何将其删除。这个问题仍然存在于中继模型中，但是可能更容易解决 - 从发布中挑选出来的主干。 这是功能分支的帮助 - 但它们具有集成成本。
Subversion允许这两种方法。后备箱不是必需品，而是一种惯例。如果你有它，一些工具更容易工作（例如Git的迁移工具）。如果你没有它，你必须手动做一些事情，但我想不出你在日常工作中会注意到的事情。
我们做 - 有点。我们不使用中继，但为我们项目的每个版本创建一个新分支。这个'标记'分支是每个版本的主干，我们通过将更改合并到旧版本来支持错误修正。
它适合我们，但我们的项目中确实有很多子项目。
我最近开始研究一个在Subversion版本库上的项目。无论是谁创建仓库都没有遵循任何特定的布局 - 他们只是将所有东西都塞进了仓库的根目录（没有中继/，没有分支/，当然也没有标签/）。我想创建一个分支来处理其他内容，但是意识到在不遵循正确布局的Subversion存储库上这么做很困难。
这当然是对的 - 我敢肯定，在这种情况下，这是一个稻草人，但提问者已经有多个分支。 – 2009-08-24 16:25:27
IME，在某些环境中，主干是交换修复和修改的好地方。也就是说，每个人都将自己的修补程序合并到到后备箱中，并且每个人都合并其他人的修复程序从后备箱。我们发现，在许多独立项目共享大量代码并且所有这些项目都贡献共享代码的环境中，这非常有用。
虽然您的环境可能有所不同。
我的Perforce论文存在的问题是，它拒绝宣传模型而没有提到主要优势，降低了合并开销。事实上，这篇论文错误地指出，“主线模式”强加“不额外的管理开销”，这是一个荒谬的主张。 “始终合并到主干”模式意味着这一点 - 您必须承担所有人必须合并的开销。这是没有意义的开销，如果你有以下情况（我们有）：
a）一个小团队（5至7名开发人员）在彼此呼喊的距离内。通信是一个非问题时，我们需要做一个分支
和
B）一个代码库，其中有曾经真的只有2大分支 - 生产分支和“发展未来的事情”。也许一旦在一个蓝色的月亮我们有3.
我想我的观点是 - 这是一个情况的事情。说“促销模式有问题”就像说“从不使用OR/M”一样。这取决于你的环境。
是的 - 我同意 - 在小团队中，沟通的开销较低，稳定版本所需的工作无论如何都涉及到每个人（因此主干要么稳定（只有错误修正），要么停滞（错误修正在不同的分支上）） – 2009-08-25 09:44:52
In我的经验虽然移动工作的开销仍然发生。 – 2009-08-25 09:45:47
我发现它很有用 - 如果在稳定期间错误级别不高，有一个地方可以进行错误修复，即使它们已经脱离了发行版。 – 2009-08-25 09:46:33
+1链接到优秀的文章！ – RichardOD 2009-08-24 15:50:17
非常好的文章，谢谢道格拉斯。 – Sebastian 2009-08-24 16:01:48
太好了 - 我得到了6张选票，问题已经提交给CW： - ）... – 2009-08-24 16:26:05