Re: conflict resolver callback question / enhancement request

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.

---------------------------------------------------------------------
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:17:18 2007