Re: conflict resolver callback question / enhancement request

On 10/12/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> On 9/6/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
>
> > > And yes, you're right: we should expand the conflict_description_t to
> > > indicate text vs. prop conflict.
> >
> > And please consider not just a boolean for this. The property name would
> > be very useful: the svn: properties are basically text and could be
> > merged with the right tool instead of just keeping either the repository
> > or local props.
>
>
> 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
>
> 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.

This looks fine to me.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org