[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Surprising behavior with 1.10 tree conflict resolver

From: Chris <devnullaccount_at_yahoo.se>
Date: Wed, 25 Apr 2018 12:03:17 +0000 (UTC)

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).

/Chris

--------------------------------------------
On Wed, 4/25/18, Stefan Sperling <stsp_at_apache.org> wrote:

 Subject: Re: Surprising behavior with 1.10 tree conflict resolver
 To: "Chris" <devnullaccount_at_yahoo.se>
 Cc: users_at_subversion.apache.org
 Date: Wednesday, April 25, 2018, 1:37 PM
 
 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
 
 -----Inline Attachment Follows-----
 
 
Received on 2018-04-25 14:03:30 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.