On Wed, Jan 30, 2013 at 01:34:06PM -0000, julianfoad_at_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?
Received on 2013-01-30 14:49:33 CET