On 10/12/07, Ben Collins-Sussman <email@example.com> wrote:
> On 9/6/07, Stefan Küng <firstname.lastname@example.org> 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
> - add new fields, and only set them when we're describing a
> 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:
> 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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Oct 12 18:26:21 2007