团队的一部分人正在处理下一个版本/冲刺，其余的人在发布到生产之前进行测试和修复上一个冲刺的错误。
下一个版本的工作部分现在想要分支，另一部分希望尽可能晚，因为一旦我们分支，他们就必须开始合并修复。
我不喜欢让任何人等待提交，因为我们还没有分支。我也不喜欢在人们不懂合并时浪费他们的时间。（并且 SVN 不合并重命名）
有什么意见或建议吗？谢谢
笔记：
这在过去是一个更严重的问题，因为我们使用带有 1.4 存储库的 tortoisesvn 1.6，这阻止了 GUI 进行分支/合并操作。所以我通过升级 repo 消除了这个障碍。至少现在团队成员应该很容易合并。
供您考虑的另一点：
考虑在 TRUNK 上保留渐进式代码（假设使用最频繁的代码是朝向新版本的代码）。从 HEAD（或之前的基线版本，如果您已对其进行标记）分支出来，以供 bugfixer 团队使用。如果他们愿意，他们可以定期修复错误并从主干合并以获取最新开发的更新。
另一方面，新的发布工作在 TRUNK 上进行，并且可以指定 TRUNK 始终代表“当前”或“生产”环境中的内容。如果您想将以前版本的修复恢复到当前版本，您可以从 bugfix 分支合并回 TRUNK。
该模型也可以在下一个发布标签之后进行迭代。
根据我的经验，这有助于最大限度地减少合并，因为错误修复的数量会更少，因此这意味着在需要时可以合并回 TRUNK 的文件更少。在大多数情况下（我说大多数不是全部:-)）情况下，修复错误的开发人员数量会更少，因此这再次意味着需要合并的文件数量更少。
HTH。
对于这类问题，我强烈推荐 Git/Mercurial。:)
但既然我知道那不是一个选择，我只想说，对于这些类型的问题，真的没有 100% 好的答案。一般来说，我倾向于在流程尽可能晚的时候才进行分支，因为分支和与 CVS/SVN 的合并往往是重量级的流程。您可以推迟分支流程的时间越长，您在许多方面的情况就越好。但正如开发新功能的团队所知道的那样，这种情况只能持续很长时间......在某些时候，延迟新功能的成本超过了推迟合并的好处。
我现在所处的位置，这通常会在新版本发布前 1-2 周（有时甚至更短）产生一个分支。但确切的时间总是会根据推动发布的具体压力以及即将发布的版本中的新功能而有所不同。
在 SVN 中，分支不一定是一个痛苦的过程——尤其是使用最新版本的 TortoiseSVN 和 SVN 客户端。它需要一些关于 VCS 和 repo 的知识，但这对于任何软件开发人员来说都是必需的。
需要考虑的是在每个开发阶段可能会发生多少新代码和多少修改。通常，冲刺/发布阶段会产生比错误修复阶段更重要的更改集。这意味着立即分支并合并较少数量的错误修复更为明智。在大多数情况下，等待分支会导致更混乱的合并。
早期分支还可以让您的错误修复更多曝光，因为它们可以由冲刺开发人员在新功能的单元和功能测试期间进行练习。更多曝光 = 更好的无错误修复。
一旦你进入一个版本的特性冻结，你必须做分支，这样开发下一个版本的团队就不会继续破坏你试图搁置的那个。试图进一步延迟分支只会导致更多问题。
如果您使用功能分支，那么这会变得更容易。所有修复都发生在主干中，您保留一个 RC 分支，您将从中发布，您可以在进行测试发布之前从主干进行批发合并。功能分支从主干合并，只有在功能准备好时才合并回主干。尽管这听起来会导致更多的合并，但它使所有合并都非常简单。
这类似于使用 DVCS 获得的工作流程，不同之处在于所有分支都清晰可见，而不是散布在开发人员的机器周围。
尽可能晚地分支。