从主干合并到 SVN 树中的开发分支时出现问题。
该项目的历史是这样的。它从一个树干开始。关于修订版 207，创建了第一个分支。然后，在修订版 331 中，感兴趣的分支从主干中分离出来。
我们现在处于修订版 384。331 之间的大部分更改是在感兴趣的分支上进行的，但少数是在主干上独立进行的。
为了使分支与主干保持一致，我想从主干合并到其中。所以我适时地这样做了：
svn merge ^/trunk .
但是，我发现各种冲突都在出现。我可能理解一些冲突，但树中的几乎所有目录和文件都会受到影响。
更糟糕的是，这些所谓的冲突中的大多数实际上是在 207 和 331 之间提交到主干的更改，因此已经合并到分支中，自从分支从主干分离后就一直存在。
比这更糟糕的是，许多所谓的冲突是树冲突，涉及被删除或重命名的文件，再次在 207 和 331 之间。因为它们不再存在于分支上，而且确实不应该存在于那里，我看不到任何解决问题的方法。
修复很复杂，因为对于几乎所有文件，分支都是正确的，因此合并，然后接受分支副本，让我没有什么可提交的，所以服务器永远不会得到合并实际上已经执行的提示出去。
我已经尝试了几件事来解决它：
svn cleanup
在我看来，这并没有做任何相关的事情。
svn checkout ^/branches/branch-of-interest new-local-copy-of-branch-of-interest
问题仍然存在于结帐的新副本中。
svn merge --record-only -r207:331 ^/trunk .
有趣的是，所谓的“仅记录”合并也试图更改我本地副本中的文件！
svn merge ^/trunk .
这产生了一大堆冲突和树冲突，即使在我与仅记录合并进行斗争之后，煞费苦心地解决了它（仅记录合并）应用的更改。
我还应该说，当我开始时，我的客户端运行的是 1.6.17，服务器运行的是 1.4.6。但是，服务器后来也升级到了 1.6.17，问题依然存在。
人们有什么办法可以解决这个问题吗？进行完全合并和逐个解析文件将非常耗时，而且在这一点上 - 出于显而易见的原因 - 我什至不相信下次我的 SVN 不会只是尝试使用相同的东西我又来了。