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

Re: Problems with property conflict callback

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2007-10-27 03:37:08 CEST

Mark and Stefan: I've fixed up the property-conflict callback logic
quite a bit in r27443, and I've written a "guide" for handling them in svn
clients. I hope this will make it easier for you guys to get good
behavior from TSVN and Subclipse!

Guide to Property-Conflicts via Interactive Callback
----------------------------------------------------

Basically, your conflict-callback used to be easy: for textual
conflicts, {base, mine, theirs} were always defined, and {merged} was
almost always present with pre-populated conflict markers.

Now, because we have conflicting property values, any of the four
files might not exist. "mine" and "theirs" might be NULL because
someone's trying to delete the property. "base" might be NULL because
both parties are trying to add the same new property.

So your conflict-callback is going to have be careful of NULL values:

* If all three files (base, mine, theirs) are provided, then you're
  free to show a difference between base and merged (assuming merged
  is not NULL, then users will see the conflict markers).

* If your conflict callback gets a NULL merged-file, then it means
  libsvn_wc did not make an attempt to merge things automatically.
  The conflict callback is welcome to attempt the merge itself; if it
  does so, then put the result in a new tmpfile somewhere and pass the
  path back in svn_wc_conflict_result_t->merged_file. (And don't
  forget to 'choose_merged' as well.)

* If you receive a NULL base-file, this means that both agents are
  trying to add the property for the first time. That's fine: you can
  still try show a diff between the 'mine' and 'theirs' file.

* If your conflict callback gets a NULL 'mine' or NULL 'theirs', it
  means that one agent is attempting to delete the property, and one
  is trying to modify it. Display this to your users however you
  wish.

* Note that it's also possible for a property conflict to happen and
  your callback to *not* get called. If both agents are trying to
  modify and existing property, and they *disagree* on the prior base
  value, then there's no way to do a 3-way merge. (For example,
  suppose one agent is trying to change property "color" from "red" to
  "green", and the other agent is trying to change the same "color"
  property from "yellow" to "blue".) In this case, t conflict
  callback isn't invoked at all; the property is marked (C)onflicted
  and a .prej file is created to describe the contextual mismatch.

* Hand-testing your interactive property handling (for sanity):

 - Both agents try to change an existing property, but to different values.

       -> CLI offers a diff between base and merged, to show the prop
          conflicts.

 - Both agents attempt to add a new property, but with different
   values.

       -> CLI offers a diff between mine and theirs, to show the
          disagreement in newly-added values.

 - One agent tries to change an existing property, other agent tries
   to delete it.

       -> CLI simply says, "You want to delete the prop, they want to
          set its value to blah." No other diff offered.

You guys may want to look at subversion/svn/conflict-callbacks.c to
examine the CLI's callback.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 27 03:37:19 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.