Interactively postpone all remaining conflicts?

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.

-Karl

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

Perforce has this, in fact.  Something like "at"
means "for the rest
of the operation, select ALL (t)heirs".  There's a
similar "am"
response, and maybe we could also do something like
"ap".

This would be a quick hack to the CLI's interactive callback
in
libsvn_client/conflict-callback.c.   Something you could do
for fun.


On Nov 6, 2007 12:28 AM, Karl Fogel <kfogelred-bean.com> 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.
>
> -Karl
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
> For additional commands, e-mail: dev-helpsubversion.tigris.org
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

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.

Ben Collins-Sussman wrote:
> Perforce has this, in fact.  Something like
"at" means "for the rest
> of the operation, select ALL (t)heirs".  There's a
similar "am"
> response, and maybe we could also do something like
"ap".

Actually, FWIW, Perforce's "at", "am"
etc. mean "accept Theirs", "Accept 
Merged" etc. Their help text doesn't indicate there's
an interactive way of 
saying "accept all the rest as ..."; you have to
stop and then run the 
"resolve" subcommand with the appropriate
command-line option like "-at". 
Likewise, a Subversion user could/would break and re-run the
merge/update 
command with "--accept=theirs" or whatever, if we
don't provide an interactive 
"all the rest" command. (Assuming that
break-and-re-start works safely...?)

(I'm not implying any opinion on the desirability of
"all the rest" commands.)

- Julian


> On Nov 6, 2007 12:28 AM, Karl Fogel <kfogelred-bean.com> 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.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

Daniel Rall <dlrcollab.net> writes:
> 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.

Given this, I agree -- let's not try for it in 1.5.  If
people really
want it, we'll hear about it, and maybe we'll feel
differently about
automatic continuation in multi-pass merges even over
conflicts by
then.  (Don't ask me why, we just might.)

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org