Re: Surprising behavior with 1.10 tree conflict resolver

Hi again,

I'm attaching a script that reproduces the behavior of checking revisions before the branch was created as well as going back to the revision before the file was created on trunk.
If you run the attached script and redirect the output to file, you'll see this:

--- Merging r3 through r5 into '.':
   C testfile
--- Recording mergeinfo for merge of r3 through r5 into '.':
 U .
Summary of conflicts:
  Tree conflicts: 1
Searching tree conflict details for 'testfile' in repository:
Checking r2...Checking r4...Checking r5...Checking r3...Checking r2...Checking r1...Checking r5... done

So despite the merge being for 3:5, it checks r2 (twice) and r1 once. As Stefan stated, this may be completely reasonable due to the data structures, but for our large and slow repo, this made merges impossible.
If there had been svn:mergeinfo on the branch, shouldn't it had been able to stop at r3 in that case? I tried this on the full repo and still seemed to have it go back further than expected.

Let me know if this is expected behavior or not and if there's anything else I can help with analyzing it. Unfortunately, I can't give access to the company-internal repo to test the actual problem.

TIA,
  Chris

--------------------------------------------
On Wed, 4/25/18, Chris <devnullaccount_at_yahoo.se> wrote:

 Subject: Re: Surprising behavior with 1.10 tree conflict resolver
 To: "Chris" <devnullaccount_at_yahoo.se>, "Stefan Sperling" <stsp_at_apache.org>
 Cc: users_at_subversion.apache.org
 Date: Wednesday, April 25, 2018, 2:03 PM
 
 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-----