Re: conflict resolver callback question / enhancement request

David Glasser wrote:
> 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.
>
> Will the API provide a way for a callback implementor to get a
> diff3-merge-style merge of line-based props (eg svn:ignore), or do the
> callbacks all have to implement that themselves?

I think the clients should do that themselves. After all, not all
properties are pure text (it's possible to set binary properties).

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