Surprising behavior with 1.10 tree conflict resolver

I'm trying out subversion 1.10 and it's going both good and bad.

The good thing is that new interactive conflict resolver works absolutely brilliantly for text conflicts. Great job everyone!
The bad news is that I can't resolve my tree conflicts.

Let me prefix this with saying that the corporate svn server I'm using is badly setup and slow as molasses (*), which may play a part here, but even without that, I don't understand the behavior I am seeing. It is probably correct as-is, but unfortunately seems to make svn 1.10 impossible to use for me.

I'm trying a merge from trunk to my branch on a project with this kind of chronology for a conflict:
* branch created at r105778 (the file "foo" exists on trunk)
* "foo" modified on trunk in r106352
* "foo" moved and renamed on branch in r106610
* merge trunk to branch in rev 107369 (first merge to the branch)

But when it hits "foo" in the resolver, it prints:

Searching tree conflict details for foo in repository:
Checking r<xxx>...

Where <xxx> started at recent changes in "foo" but is going backwards to revisions long before the branch root, i.e. revisions before 105778. I don't understand how any of these should affect the merge resolution since they are older than when I created the branch so I'm guaranteed to already have those revisions (?). I even *think* it is continuing further back than when the foo was added to trunk. And this is taking a really really long time with our server. We're talking minutes per revision, even causing timeout from the server so I can't resolve the conflict. Shouldn't it have stopped going backwards beyond the revisions that I branched off on? (the "--stop-on-copy" revision)
I'm getting the same with all files that have been moved/removed from the branch and modified on trunk

The resolution I want is to just mark the file as deleted and move on since I know the change on trunk does not affect the decision to delete the file, but I'm not getting there. Our slow server is definitely a part of the problem, but isn't it also strange how far back it goes to find the problem?

I even tried manually setting svn:mergeinfo on the branch to include a trunk revision from the start of the branch, but it still tried going back beyond that point which was my first guess at what was happening.

If you think this is working as it should and it is just our horrible server deployment, I guess we'll have to avoid upgrading our clients to 1.10 which would be sad considering how good the text conflict resolver looks.

(*) Believe me, I've tried getting corporate IT to fix the deployment, but that's a brick wall I'm not going to succeed in punching through

BR,
  Chris
Received on 2018-04-25 13:04:32 CEST