解决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 不会只是尝试拉出相同的东西我重新来过。
I have a problem when merging from the trunk into a development branch in an SVN tree.
The history of the project is this. It started with just a single trunk. About revision 207, the first branch was created. Then, at revision 331, the branch of interest was split off from the trunk.
We're now at revision 384. Most of the changes between 331 have been made on the branch of interest, but a few have independently been made on the trunk.
So that the branch stays in tune with the trunk, I wanted to merge from the trunk into it. So I duly did so:
svn merge ^/trunk .
However, I find that all manner of conflicts are popping up. A few conflicts I might understand, but almost all directories and files in the tree are affected.
What makes it worse is that most of these purported conflicts are actually changes that were committed to the trunk between 207 and 331, and are therefore already incorporated in the branch, having been there since the branch was split off from the trunk.
What's worse than that is that a number of the supposed conflicts are tree conflicts, involving files that were deleted or renamed, again between 207 and 331. Because they don't exist on the branch any more, and indeed shouldn't exist there, I can't see any way to resolve the problem.
A fix is complicated because for almost all files, the branch is correct, and so a merge in, followed by accepting the branch copy, leaves me with nothing to commit, so the server never gets the hint that the merge has in fact been carried out.
I've tried several things to fix it:
svn cleanup
It seemed to me that this didn't do anything pertinent.
svn checkout ^/branches/branch-of-interest new-local-copy-of-branch-of-interest
The problem persisted into the new copy of the checkout.
svn merge --record-only -r207:331 ^/trunk .
Interestingly enough, the supposedly "record-only" merge also tried to change the files in my local copy!
svn merge ^/trunk .
This generated a whole pile of conflicts and tree conflicts, even after I'd fought with the record-only merge, painstakingly resolving the changes it (the record-only merge) applied.
I should also say that when I started, my client was running 1.6.17 and the server 1.4.6. However, the server has since been upgraded to 1.6.17 too, and the problem persists.
Is there any way people have found to solve this problem? Doing a full merge and resolving files one by one would be incredibly time-consuming, and at this point - for obvious reasons - I don't even have confidence that the next time my SVN wouldn't just try to pull the same thing on me all over again.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
事实证明，问题出在与存储库关联的数据库版本上。即使客户端和服务器已升级到最新版本，数据库仍采用旧格式，无法跟踪合并。
升级到最新的数据库版本解决了这个问题，让我可以毫无问题地进行合并。特别是，我们在托管服务器和存储库的计算机上使用了这些命令：
It turns out that the problem lay in the database version associated with the repository. Even after the client and server had been upgraded to the latest version, the database was still in an old format that didn't track merges.
Upgrading to the latest database version solved the problem and allowed me to merge with no trouble. Particularly, we used these commands on the machine hosting the server and repo: