Re: svn commit: r1440411 - /subversion/trunk/subversion/svn/conflict-callbacks.c

[Stefan Sperling <st...@elego.de>]

On Wed, Jan 30, 2013 at 01:34:06PM -0000, julianfoad@apache.org wrote:
> Author: julianfoad
> Date: Wed Jan 30 13:34:06 2013
> New Revision: 1440411
> 
> URL: http://svn.apache.org/viewvc?rev=1440411&view=rev
> Log:
> Make the interactive conflict resolver code more table-driven: the responses
> that simply choose a return value now get it from the table. Make the 'help'
> response uniformly available with all four types of conflicts.
> 
> * subversion/svn/conflict-callbacks.c
>   (resolver_option_t): Add a 'choice' field.
>   (text_conflict_options, prop_conflict_options,
>    obstructed_add_options, tree_conflict_options): Add the simple responses
>     in the new column.
>   (prompt_user): New function.
>   (handle_text_conflict, handle_prop_conflict,
>    handle_tree_conflict, handle_obstructed_add): Factor out the prompting
>     and choosing of simple responses.
> 
> Modified:
>     subversion/trunk/subversion/svn/conflict-callbacks.c

Hi Julian,

nice work! I have one question about this that I've been wanting
to ask for a while, see below.

> Modified: subversion/trunk/subversion/svn/conflict-callbacks.c
> URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/svn/conflict-callbacks.c?rev=1440411&r1=1440410&r2=1440411&view=diff
> ==============================================================================
> --- subversion/trunk/subversion/svn/conflict-callbacks.c (original)
> +++ subversion/trunk/subversion/svn/conflict-callbacks.c Wed Jan 30 13:34:06 2013

>  /* Resolver options for a tree conflict */
>  static const resolver_option_t tree_conflict_options[] =
>  {
> -  { "p",  "postpone",         N_("resolve the conflict later") },
> -  { "r",  "resolved",         N_("accept current working copy state") },
> -  { "mc", "mine-conflict",    N_("prefer local change") },
> -  { "tc", "theirs-conflict",  N_("prefer incoming change") },
> -  { "h",  "show help",        N_("show this help") },
> +  { "p",  "postpone",         N_("resolve the conflict later"),
> +                              svn_wc_conflict_choose_postpone },
> +  { "r",  "resolved",         N_("accept current working copy state"),
> +                              svn_wc_conflict_choose_merged },
> +  { "mc", "mine-conflict",    N_("prefer local change"),
> +                              svn_wc_conflict_choose_mine_conflict },
> +  { "tc", "theirs-conflict",  N_("prefer incoming change"),
> +                              svn_wc_conflict_choose_theirs_conflict },
> +  { "h",  "help",             N_("show this help (also '?')"), -1 },
>    { NULL }
>  };

What I would like here is the ability to plug in custom descriptions
to better describe the actual effect of some options in particular
tree conflict scenarios.

Consider the current update-move work. There, if the user chooses 'mc'
at the conflict prompt, we apply the update to the moved-away subtree.

And if the user chooses 'tc', we break the move and leave the copied
half of the move as a simple copy (rather than as a move). Additionally,
the delete-half can either be left deleted or be reverted so that changes
brought in by the update for the delete-half become visible in the working
copy.

So I would like to describe more clearly what will happen if the user
picks one of these options. Something like:

    (mc) mine-conflict    - apply the update to the move destination
    (tc) theirs-conflict  - transform the move into a copy and leave
                            the move source deleted
    (tf) theirs-full      - transform the move into a copy and revert
                            deletion of the move source
                            
I think the best way of doing this would be to have a special
tree conflict options table that overrides the generic table
in certain cases.

What do you think?