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
Received on 2018-08-29 14:29:27 CEST