Surprising behavior with 1.10 tree conflict resolver

[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 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

[Stefan Sperling]

Post by 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 me.
* 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)
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

[Chris]

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 <***@apache.org> wrote:

Subject: Re: Surprising behavior with 1.10 tree conflict resolver
To: "Chris" <***@yahoo.se>
Cc: ***@subversion.apache.org
Date: Wednesday, April 25, 2018, 1:37 PM

On Wed, Apr 25, 2018 at 11:04:13AM +0000, Chris

Post by Chris
I'm trying out subversion 1.10 and

it's going both good and bad.

Post by Chris
The good thing is that new interactive

conflict resolver works absolutely brilliantly for text
conflicts. Great job everyone!

Post by Chris
The bad

news is that I can't resolve my tree conflicts.

Post by Chris
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.

Post by Chris
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)

Post by Chris
* "foo" modified on

trunk in r106352

Post by Chris
* "foo"

moved and renamed on branch in r106610
* merge trunk to branch in rev 107369 (first merge to the
branch)

Post by Chris
But when
Searching tree

conflict details for foo in repository:
Checking r<xxx>...

Post by Chris
Where <xxx> started at recent

changes in "foo" but is going backwards to

Post by Chris
revisions long before the branch root,

i.e. revisions before 105778. I don't

Post by Chris
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

Post by Chris
revisions (?). I

even *think* it is continuing further back than when the
foo

Post by Chris
was added to trunk. And this is

taking a really really long time with our

Post by Chris
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

Post by Chris
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-----

[Chris]

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 <***@yahoo.se> wrote:

Subject: Re: Surprising behavior with 1.10 tree conflict resolver
To: "Chris" <***@yahoo.se>, "Stefan Sperling" <***@apache.org>
Cc: ***@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 <***@apache.org>
wrote:

Subject: Re: Surprising behavior with
1.10 tree conflict resolver
To: "Chris" <***@yahoo.se>
Cc: ***@subversion.apache.org
Date: Wednesday, April 25, 2018, 1:37
PM

On Wed, Apr 25, 2018 at 11:04:13AM
+0000, Chris

Post by Chris
I'm trying out subversion 1.10

and
it's going both good and bad.

Post by Chris
The good thing is that new

interactive
conflict resolver works absolutely
brilliantly for text
conflicts. Great job everyone!

Post by Chris
The bad

news is that I can't resolve my tree
conflicts.

Post by Chris
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.

Post by Chris
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)

Post by Chris
* "foo" modified on

trunk in r106352

Post by Chris
* "foo"

moved and renamed on branch in
r106610
* merge trunk to branch in rev 107369
(first merge to the
branch)

Post by Chris
But when

it hits "foo" in the resolver, it

Post by Chris
Searching tree

conflict details for foo in
repository:
Checking r<xxx>...

Post by Chris
Where <xxx> started at

recent
changes in "foo" but is going
backwards to

Post by Chris
revisions long before the branch

root,
i.e. revisions before 105778. I don't

Post by Chris
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

Post by Chris
revisions (?). I

even *think* it is continuing further
back than when the
foo

Post by Chris
was added to trunk. And this is

taking a really really long time with
our

Post by Chris
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

Post by Chris
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-----

[Stefan Sperling]

Post by Chris
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.

Thank you Chris!

I have filed https://issues.apache.org/jira/browse/SVN-4740

[Stefan Sperling]

Post by Stefan Sperling

Post by Chris
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.

Thank you Chris!
I have filed https://issues.apache.org/jira/browse/SVN-4740

I have finally found some time to look into this.

The fix turned out not to be difficult - the problem was a hard-coded
'revision 0' function paramter which could be replaced with a youngest
common ancestor revision instead. History traversal now stops there.

The fix has been nominated for 1.10.1. Barring unexpected problems
it should become part of that release.

Thanks again for your script! It helped me a lot.