该团队的一部分正在开发下一个版本/ sprint，其他则负责测试并修复之前的sprint。计划发布分支
的部分在下一版本的工作现在想的分支，另一部分尽快希望它尽可能晚，因为他们将不得不开始合并修复，因为我们的分支。
我不喜欢让任何人等待提交，因为我们还没有分支。当他们不理解合并时，我也不喜欢浪费人们的时间。 （和SVN不合并重命名）
有什么意见或建议吗？由于
注：
这是因为我们使用TortoiseSVN的1.6与1.4回购其阻止了GUI从做分支/合并操作，在过去一个糟糕的问题。所以我通过升级回购消除了这个障碍。现在，团队成员应该很容易合并。
为您考虑的另一点：
请保留逐行代码（最活跃使用的代码被认为是一个迈向新更新，最新版本的标题）在树干上。从HEAD分支出来（或者之前的基线版本，如果您已经标记了它的话）以供bug fixer团队使用。他们可以定期修复错误并定期从主干合并，以便从最新的开发中获取更新（如果他们愿意的话）。
，另一方面新版本工作进展的躯干和行李箱可以专款专用，始终代表的是在“当前”或“生产”的环境。如果您想要将以前版本的修复恢复到curent版本，您可以从bugfix分支恢复到TRUNK。
该模型可以在下一个版本的标签后进行迭代为好。
在我的经验，这有助于最大限度地减少合并为bug修复将在数少所以这意味着较小的文件，并在需要时合并回主干。在大多数情况下（我说绝大多数情况下都是:-)）的情况下，bug修复的开发人员数量会少一些，这意味着需要合并的文件数量较少。
HTH。
我强烈建议Git/Mercurial解决这些问题。 :)
但因为我知道那不是一种选择，我只想说，真的有没有100％的巨大回答这些类型的问题。一般来说，我倾向于在分支过程尽可能晚的时候不支持分支，因为与CVS/SVN的分支和合并往往是重量级的过程。您可以推迟分支流程的时间越长，您在许多方面就越好。但是，研究新功能的团队知道，这只能持续很长时间......在某种程度上，延迟新功能的成本超过了推迟合并的好处。
哪里我现在，这往往是一个新版本的发布结果公布之前的一个分支1-2周（有时甚至更低）。但确切的时间总是随着推动发布的具体压力以及即将发布的新功能而变化。
分支不必在SVN一个痛苦的过程 - 尤其是在TortoiseSVN的最新版本和SVN客户端。它需要一些关于VCS和回购的知识，但这对任何软件开发人员都是必需的。
一些思考很多新的代码，以及如何许多修改怎么可能在开发的每个阶段发生。通常情况下，sprint/release阶段会产生比错误修复阶段更大的更改集。这意味着立即分支并合并较少数量的错误修复程序会更加明智。在大多数情况下，等待分支会导致更混乱的合并。
早期的分支还可以让您的错误修复更具有曝光度，因为它们可以在单元和新功能的功能测试期间由短跑开发人员执行。更多曝光=更好的无错修复。
一旦进入功能冻结发布，您必须执行该分支，以便在下一个版本上工作的团队不会继续破坏您尝试放置的那个团队。试图推迟一个分支比这更进一步会导致更多问题。
如果您使用功能分支，那么这变得更容易。所有的修复都发生在trunk中，你保留一个RC分支，你可以从中发布，你可以在做测试版本之前从trunk到批量合并。功能分支从主干合并，只有在功能准备就绪后才能合并回主干。虽然这听起来像会导致更多的合并，但它使所有合并非常简单。
这是类似的，你会得到一个DVCS，只是所有的树枝都在众目睽睽下，而不是围绕开发者的机器传播的工作流程。
分支尽可能晚。