subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris <devnullacco...@yahoo.se>
Subject Surprising behavior with 1.10 tree conflict resolver
Date Wed, 25 Apr 2018 11:04:13 GMT
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

Mime
View raw message