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!
