我的开发小组遵循Subversion中不稳定的主干，稳定的分支模式。每个月，都会从主干创建一个稳定的发布分支。有时，需要将更改从这些发布分支合并到后续发布分支中，最终合并到主干中。
问题在于，在过去几个月中，所有这些分支的合并都是错误的。由于开发人员误解了他们需要合并的修订版，因此很多修订版都被忽略了。
示例不正确的合并历史记录如下所示：
------------------------------------------------------------------------
r57 | Bob | 2008-11-27 04:02:46 -0600 (Thu, 27 Nov 2008) | 1 line
action:merge; origin:branches/1; target:branches/2; range:28-55
------------------------------------------------------------------------
r28 | Alice | 2008-11-25 10:14:00 -0600 (Tue, 25 Nov 2008) | 1 line
action:merge; origin:branches/1; target:branches/2; range:10-25
在这里，Bob应该从r25开始他的合并，其中Alice的合并结束，而不是r28。
所以现在我有6个分支，这些分支自10月初以这种方式被错误地合并。这会导致测试失败以及主干中的许多回归。所以现在，我想回去合并所有错过的更改。
有一种简单且正确的方法吗？我目前的计划是回到起点并开始合并每个差距。所以在这个例子中，我将从分支1到分支2合并修订25-28。但是我期待很多冲突，我希望有更好的方法。
确实没有快速简便的解决方法。强制开发人员在Subversion中维护多个并发分支容易出错且耗时。在这种情况下，许多开发人员的签到注释都是不准确的。所以真的没有办法回去追溯他们的步伐。相反，我们将完全测试最近的分支并关闭其余分支。
答案 0 :(得分：1)
如果开发人员在整个过程中检查他们在分支中的更改，那么在合并之前是否无法创建新分支，正确合并更改，然后合并他们的新代码？也许我错过了什么。
我不熟悉各种Subversion模式，但我的公司遵循一个过程，我们的主干总是稳定的，开发人员不能改变它（只能改变分支）。我们从未遇到合并问题，我们在SVN中有超过10,000个修订版和100个分支。我只是提出这个问题，因为如果有多个开发人员遇到合并问题，听起来你的流程/模式存在重大缺陷。
答案 1 :(得分：0)
好吧，要获得所有内容，您只需合并到没有特定修订版的网址即可。如：
cd /path/to/working/copy/of/stable/brunch
svn merge https://company.com/repo/project/branch/stable https://company.com/repo/project/trunk
通过这种方式，您可以从主干中获得您忘记合并到稳定的所有内容。检查，还原您不需要的东西，并提交。