svn中主干到分支合并问题的解决

当从主干合并到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会不会再次尝试将同样的事情推到我身上。

事实证明，问题出在与存储库关联的数据库版本上。即使在客户机和服务器升级到最新版本后，数据库仍然是旧格式，无法跟踪合并

升级到最新的数据库版本解决了这个问题，使我可以毫无困难地进行合并。特别是，我们在托管服务器和repo的机器上使用了以下命令：

svnadmin upgrade /path/to/repository
svn-populate-node-origins-index /path/to/repository

---

你可能会在树干上找些奇怪的东西。我曾经看到一个类似的问题，当主干被删除，然后通过合并恢复。谢谢约翰。实际上，我怀疑这可能是因为SVN存储库数据库仍然是1.4格式，因此无法跟踪合并。我已经联系了回购协议的维护人员，要求他对其进行升级。我看看这能不能解决问题。