On 29.08.2018 12:54, 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). > > Please add an option to disable conflict resolution entirely.
Would not one of the --accept option values work? E.g., `--accept=theirs-conflict', though that would also affect how the file contents are merged. -- Brane
