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