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 <s...@elego.de> wrote: Subject: Re: Tree conflict resolution considered harmful To: "Dag-Erling Smørgrav" <d...@des.no> Cc: users@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-----