从中继线合并到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不会尝试同样的东西我一遍又一遍。
答案 0 :(得分：0)
事实证明，问题在于与存储库关联的数据库版本。即使客户端和服务器已升级到最新版本，数据库仍然是旧格式，不跟踪合并。
升级到最新的数据库版本解决了这个问题，让我可以毫无困难地合并。特别是，我们在托管服务器和repo的机器上使用了这些命令：
svnadmin upgrade /path/to/repository
svn-populate-node-origins-index /path/to/repository