[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: conflict resolver callback question / enhancement request

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-10-12 18:43:36 CEST

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?


David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 12 18:43:46 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.