1
从树干合并到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不会只是尝试在拉同样的事情我一遍又一遍。
您可能会通过日志查看干线上的奇怪事情。我看到一个类似的问题，一旦移除了主干，然后通过合并来恢复。 –
谢谢约翰。实际上，我怀疑这可能是因为SVN存储库数据库仍然是1.4格式，因此无法跟踪合并。我已经联系了回购维护者，要求他升级它。我会看看如果解决了这个问题。 – Valtandor