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!
Received on 2018-08-29 17:39:46 CEST