subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris <>
Subject Re: Surprising behavior with 1.10 tree conflict resolver
Date Wed, 25 Apr 2018 12:03:17 GMT
Hi Stefan and thanks for the reply.
(sorry about the top-posting, yahoo's webmail isn't made for proper mail usage)

Good idea to try the non-interactive and then resolve after, that seems to get me out of the
bind I got into, but I'll probably tell our users to stick to 1.9 for the time being.

I'm not sure I'll be able to recreate a test for the strange behavior since it may have to
do with this being a very large and very old repo that I'm working on. But I'll give it a
try as soon as I have some time to spare and post the result here (or the failure to repeat
it in a simple script).


On Wed, 4/25/18, Stefan Sperling <> wrote:

 Subject: Re: Surprising behavior with 1.10 tree conflict resolver
 To: "Chris" <>
 Date: Wednesday, April 25, 2018, 1:37 PM
 On Wed, Apr 25, 2018 at 11:04:13AM +0000, Chris
 > 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
 > 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
 > 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
 > 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
 expectations are not unreasonable but keep in mind that the
 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
 possible fix the behaviour. Could you try to write a script
 starts by creating a fresh and empty
 repository, adds files and directories
 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
 releases and release candidates.
 Feedback such as yours is very much 
 appreciated because we cannot improve the
 resolver without it.
 -----Inline Attachment Follows-----

View raw message