Re: Interactively postpone all remaining conflicts?

On Mon, 05 Nov 2007, Karl Fogel wrote:

> I recently did a massive merge, and by about the 10th conflict prompt...
>
> Conflict discovered in 'subversion/libsvn_ra_local/ra_plugin.c'.
> Select: (p)ostpone, (d)iff, (e)dit, (h)elp for more options : h
> (p)ostpone - mark the conflict to be resolved later
> (d)iff - show all changes made to merged file
> (e)dit - change merged file in an editor
> (r)esolved - accept merged version of file
> (m)ine - accept my version of file
> (t)heirs - accept their version of file
> (l)aunch - use third-party tool to resolve conflict
> (h)elp - show this list
>
> ...I really wanted an option for "postpone all". (For that matter,
> there might be circumstances where "resolve all", "use mine for all",
> etc might be useful, but probably "postpone all" would be the common
> case. If we want to generalize it, then maybe "*", as in "LETTER*",
> could be the trick for the command-line client.)
>
> Thoughts? I have no idea if this would be easy or hard to implement,
> I first wanted to get a sense of whether we like it.

It would be fairly trivial to implement -- we already support runtime
configuration which gives analogous behavior via:

  [miscellany]
  interactive-conflicts = no

For 'update' and 'switch', supporting this via during interactive
conflict resolution makes sense, but -- at least for 'update' -- is
perhaps not as useful as during 'merge'.

For 'merge', there is an unfortunate downside here. When conflicts
occur during a merge that involves multiple merge passes, subsequent
merge passes will be aborted (until conflicts are manually resolved).
This comes up in two situations:

1) Your merge target has mergeinfo which causes one of the revision
   ranges that you want to merge to be split into multiple ranges.

   Example: You attempt 'svn merge -r 3:7', and r6 has already been
   merged into your WC, the revision range will cause the merge to be
   split into two passes, -r 3:5 and -r 6:7.

2) You provide multiple non-contiguous revision ranges to 'svn merge'.

   Example: You attempt 'svn merge -r 3:5,6:7'.

Until we can more gracefully support the case where a merge conflict
occurs before the final pass of a multi-pass 'merge' operation, I
hesitate to offer this feature for 'merge'. And while it might be
convenient now if we could determine that a merge required only a
single pass (using a callback from the cmdline-client into
libsvn_client), this would result in a UI inconsistency.