On Wed, Apr 25, 2018 at 11:04:13AM +0000, Chris wrote:
> 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)
Your expectations are not unreasonable but keep in mind that the resolver
works in the context of one particular file or directory. When it traces
history back and traverses copies it cannot tell whether those copies
were creating a new branch or copy an item within a branch; in the data
model, these twoI cases look 100% alike.
We will need a more concrete example to confirm the problem and
if possible fix the behaviour. Could you try to write a script which
starts by creating a fresh and empty repository, adds files and directories
as necessary, and creates this specific tree conflict situation where it
traces history further back than necessary? That would help us a lot.
As a workaround, if this is a blocking issue for you, you could run
problematic merges with --non-interactive. This will postpone all
conflicts and suppress the interactive resolver. This allows you to
resolve the problematic conflict manually as you would have done
in SVN 1.9. Once the problematic conflict has been resolved, you can
resolve all remaining conflicts interactively by running 'svn resolve'.
Problems like this are not expected but unfortunately not inevitable either.
The resolver is new in this release and has not seen much real world testing,
even though we gave the community some early opportunities in form of alpha
releases and release candidates. Feedback such as yours is very much
appreciated because we cannot improve the resolver without it.
Thanks,
Stefan
Received on 2018-04-25 13:37:27 CEST