Subclipse 合并问题 - 试运行与合并结果不匹配
我在 Eclipse 中使用 Subclipse 1.6x 插件。首先让我解释一下这个场景：
假设我的项目主干的修订版为 r1 到 r100。 在修订版 r100 中，我创建了一个分支并开始将 r101 提交到 r105。 此时，我想我将从主干引入任何更改，以便更新我的分支。
但由于合并错误，我最终将 r80 从主干合并到我的分支，并将其作为修订版 r106 提交。因此，我恢复分支中 r106 中的更改，并向该分支再次提交 r107。
在此期间，主干中出现了 r108 和 r 109 的提交。 现在，在恢复 r106 中的错误提交后，我正确地将从主干到 r109 的所有更改引入到我的分支（通过合并），以便我的分支是最新的，并将其作为 r110 提交到我的分支。
一切都很好。现在我决定不需要分支，所以让我将分支 (r110) 中的所有更改合并回主干。因此，在这次合并之后，我应该看到的只是我在分支中所做的更改（修订版 r 101 以及后来在该分支中），因为我的分支与主干是最新的。
我做一个团队->合并 From url 作为主干，To url 作为我的分支路径。 From 修订版是主干 (r109) 中的最后合并修订版，而使用的 To 修订版是我的分支 (r110) 中的最新修订版。我尝试了试运行，并在“合并”窗口中创建了“统一差异文件”选项。它们看起来都是正确的，唯一更新的文件是我在分支中更改的文件。
现在我运行合并，合并结果与空运行不同。首先，它正确地合并了 Dry Run 显示的文件（这是我所期望的）。但它并不止于此。然后它会尝试这样的事情： --- 通过 r110 合并 r80 （可能是因为我在分支中合并错误？？？）
，然后执行以下操作： ---反向合并r110至r80。
最终结果是完全按照空运行结果合并我的所有更改，加上对其他文件的大量更新/更改（我猜是由于第二次合并和反向合并）。
关于为什么会发生这种情况以及如何使合并结果正确/与试运行结果相同有什么想法吗？即使创建的统一差异文件也是正确的。
感谢您阅读这篇冗长的文章。
I'm using Subclipse 1.6x plugin in Eclipse. Let me explain the scenario first:
Say I have the trunk of my project with revisions r1 to r100.
At revision r100 I created a branch and started committing say r101 to r105.
At this point, I thought I will bring in any changes from trunk so that my branch is updated.
But due to a merging mistake, I end up merging r80 from trunk to my branch and committed it as revision r106. So I revert my change in r106 in the branch and do another commit r107 to this branch.
During this time there has been commits say r108 and r 109 in the trunk.
Now after reverting my bad commit in r106, I correctly bring in all changes from trunk until r109 to my branch (by merging) so that my branch is up to date, and commits this to my branch as r110.
All is good. Now I decided I don't need the branch so let me merge all changes in branch (r110) back to trunk. So after this merge all I should see is the changes I made in the branch (revisions r 101 and later in that branch) as my branch is up to date with trunk.
I do a Team -> Merge with From url as trunk and To url as my branch path. The From revision is the last merged revision in trunk (r109) and the To revision used is the latest in my branch (r110). I tried a Dry Run and also creating a Unified Diff file option in the Merge window. Both of them looks correct and the only updated files are those I changed in my branch.
Now I run the Merge and and the merge result is different from Dry Run. First it correctly merges files shown by Dry Run (which is what I expected). But it doesn't stop there. It then tries something like this:
--- Merging r80 through r110 (May be because of my wrong merge in the branch???)
and then does something like:
--- Reverse-merging r110 through r80.
The end result was merging in all my changes exactly as the Dry Run result plus a lot updates/changes to other files (due to second Merging and reverse-merging I guess).
Any thoughts on why this might be happening and how to make the merge result correct/same as the Dry Run result? Even the Unified diff file created is correct.
Thanks for reading through the lengthy post.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
自 Subversion 1.5 和引入合并跟踪以来，Subclipse 合并对话框就不再工作。我建议您安装 Subclipse 更新站点上包含的 CollabNet Merge Client 插件，看看是否获得相同的结果。
团队>如果安装了此客户端，合并选项应该会弹出一个向导。
The Subclipse merge dialog has not been worked on since before Subversion 1.5 and the introduction of merge tracking. I would suggest you install the CollabNet Merge Client plugin that is included on the Subclipse update site and see if you get the same results.
The Team > Merge option should bring up a wizard if this client is installed.
好吧，我解决了这个问题，或者至少为我的案例解决了这个问题。问题是因为在我的分支上，我错误地从主干合并了 r80 并提交为 r106。然后我做了团队>恢复>最后一次提交以恢复此合并提交并将其检查为新提交 r107。
这有两个问题。首先，这不是在 SVN 中恢复合并提交的最佳方法。谷歌了解更多详情。
第二个问题是，当您将这些更改（在多个提交中）合并回主干时，SVN 会尝试将每个提交一一应用到主干。当我通过合并 r80 搞乱了分支上的 r106 时，SVN 由于文件的祖先冲突而对更改感到困惑。为了避免这种情况，并告诉 SVN 不要担心祖先，而只是将分支中的差异/更改合并到主干，请选中“合并”窗口中的“忽略祖先”选项。这解决了我的问题。
另请注意，在 SVN 合并中，Dry Run 的结果相当于在文件之间运行 Diff。但是，当您进行合并时，它会查看文件的祖先，并逐一引入每个提交来进行合并。因此，结果可能并不总是相同。 SVN 文档中有更多关于此的详细信息。
这是我从我的经验中了解到的，并将其发布在这里作为答案，因为我的帖子没有收到任何其他回复。如果我不完全正确，请添加任何评论。
Ok I figured this out or at least solved it for my case. The issue was because on my branch I wrongly merged r80 from trunk and committed as r106. Then I did Team > Revert > last commit to revert this merge-commit and checked this as a new commit r107.
There are 2 issues with this. First this is not the best way to revert a merge commit in SVN. Google for more details.
Second issue is when you merge these changes (in multiple commits) back to trunk, SVN will try to apply each commit one by one to the trunk. As I messed up r106 on branch by merging r80, SVN gets confused about the change because of conflicting ancestry for the files. In order to avoid this, and to tell SVN don't worry about the ancestry but just merge the differences/changes in my branch to trunk, check the "Ignore ancestry" option in the Merge window. This took care of the problem for me.
Also as a side note, in SVN merge, the result of Dry Run is equivalent to running Diff between the files. But when you do the Merge, it will look into the ancestry of the file and brings in each commit one by one to do the Merge. Hence the results may not always be the same. There is more details on this in SVN documentation.
This is what I understood from my experience and am posting this here as answer as I didn't get any other responses to my post. Please add any comments if I'm not fully correct.