Hi,
this seems to be the same issue that I reported back here (https://mail-archives.apache.org/mod_mbox/subversion-users/201804.mbox/browser). The bug fix that Stefan Sperling did for 1.10.2 has helped in some of my merges by breaking off earlier, but it is still equally slow at checking each revision. The case reported in this thread seems to have the conflict far back so I guess that's why the mitigation doesn't work here.
Unfortunately, I can't provide any more data on what happens (company-internal server), but I might be able to test run something if you have some theories on what to test.
By the way, if I remember correctly, --quiet works to stop the resolver, but --non-interactive did not.
/Chris
--------------------------------------------
On Wed, 8/29/18, Stefan Sperling <stsp_at_elego.de> wrote:
Subject: Re: Tree conflict resolution considered harmful
To: "Dag-Erling Smørgrav" <des_at_des.no>
Cc: users_at_subversion.apache.org
Date: Wednesday, August 29, 2018, 5:39 PM
On Wed, Aug 29, 2018 at 12:54:43PM +0200,
Dag-Erling Smørgrav wrote:
> I'm using
Subversion 1.10.2 to perform a non-interactive merge with
> around 15 tree conflicts (files that exist
on the source branch but have
> been
deleted from the target branch). It spends exactly two
hours on
> each conflict before the
connection is killed and it gives up and moves
> on to the next. Here's an excerpt
from ktrace showing svn's attempt to
> resolve the first conflict:
>
> 33821 svn
35.021454 GIO fd 1 wrote 20 bytes
>
"\rChecking r338344..."
> --
> 33821 svn
40.898214 GIO fd 1 wrote 20 bytes
> "\rChecking
r338059..."
> 33821 svn
40.898328 GIO fd 1 wrote 20 bytes
>
"\rChecking r333678..."
> 33821 svn 40.898412 GIO fd 1
wrote 20 bytes
>
"\rChecking r333677..."
> --
> 33821 svn 40.900558 GIO fd 1
wrote 20 bytes
>
"\rChecking r333490..."
> --
> 33821 svn 77.091446 GIO fd 1
wrote 20 bytes
>
"\rChecking r333389..."
> --
> 33821 svn 95.000296 GIO fd 1
wrote 20 bytes
>
"\rChecking r333300..."
> --
> 33821 svn 95.001008 GIO fd 1
wrote 20 bytes
>
"\rChecking r326169..."
> --
> 33821 svn 671.067538 GIO fd 1
wrote 20 bytes
>
"\rChecking r322052..."
> --
> 33821 svn 671.337258 GIO fd 1
wrote 20 bytes
>
"\rChecking r321369..."
> --
> 33821 svn 7240.543297 GIO fd
2 wrote 62 bytes
> "svn:
warning: W210002: Network connection closed unexpectedly
>
> The third column is
the time elapsed since the start of the process.
>
> The actual conflict
is in r294466, which removed the file in question
> from the target branch. The revision
it's stuck on, r321369, only
>
touched the svn:mergeinfo property on the current directory
(propagated
> down from a merge higher up
in the tree).
This
does indeed look like a problem.
Unfortunately, you're not providing
sufficient information. Ktrace tells
us that
time was spent somewhere. But it does not tell us what this
time
was actually spent on.
Could you provide a shell
script I can use to actually run the problematic
merge myself in a working copy of the
appropriate subdirectory of the FreeBSD
repository? Ideally, such a script would assume
nothing beyond a new empty
directory and an
'svn' binary in $PATH, and then allow me to proceed
to the
actual problem you were seeing.
I'll run this script on OpenBSD, so a ksh
compatible script would be nice.
If you could take the time to
provide that, then I will take the time to look
into the problem. But your report so far
doesn't provide enough material for
me
to chew on.
Thanks!
-----Inline Attachment Follows-----
Received on 2018-08-30 08:16:19 CEST