Re: conflict resolver callback question / enhancement request

Ben Collins-Sussman wrote:

> Here's my interactive-prop-conflict design. Code forthcoming.
> It should make both Mark and Stefan happy.
>
> The only property actions are 'set' and 'delete'. Thus there are only
> 2 types of prop conflicts:
>
> - two people try to set the same property to different values
> - one person sets a prop, another person deletes it
>
> (Both people deleting a prop is a mergeable change, as is two propsets
> to the same value.)
>
> In svn 1.4, when a property conflict happens, libsvn_wc just marks the
> file conflicted and creates a "foo.c.prej" file that describes the
> conflict. (The contents of the file are something like: "Hey, your
> local edit sets the property 'foo' to 'bar', but the repository wants
> to set 'foo' to 'baz'.")
>
>
> Proposal to extend our interactive conflict callback for props:
>
> - Invoke conflict callback for *each* property conflict discovered.
> This means that the conflict callback might be invoked many times
> on the same path -- e.g. once for a text conflict, and N more
> times for N property conflicts on the same file.
>
> - svn_wc_conflict_description_t is expanded to describe a property
> conflict:
>
> - add new fields, and only set them when we're describing a
> prop-conflict:
>
> const char *propname;
> svn_string_t *base_propvalue;
> svn_string_t *their_propvalue;
> svn_string_t *my_propvalue;
>
> - the "action" field is either 'edit' or 'delete'... (and
> 'their_propvalue' is correspondingly non-NULL or NULL.)
>
> - the "reason" field is either 'edited' or 'deleted'... (and
> 'my_propvalue) is correspondingly non-NULL or NULL.)
>
> - svn_wc_conflict_result_t is expanded to describe the resolution of
> a property conflict:
>
> - add a new field:
>
> svn_string_t *merged_propvalue;
>
> - add new enums:
>
> svn_wc_conflict_result_choose_base_propvalue
> svn_wc_conflict_result_choose_their_propvalue
> svn_wc_conflict_result_choose_my_propvalue
> svn_wc_conflict_result_choose_mergede_propvalue

Is a new enum really necessary? I mean, the callback doesn't get called
for two conflicts at the same time (file and prop conflict). So the
existing enum should be fine.

> As one would expect, returning one of these new result-codes tells
> libsvn_wc to install one of the three original propvalues, or
> to use the new 'merged_propvalue' that the callback is providing.
>
> - returning 'svn_wc_conflict_result_conflicted' tells libsvn_wc
> to just mark the file conflicted, create the usual .prej file,
> and allow conflict resolution to be postponed for later.

Looks good!

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org