|
1.1.10
by Matthias Klose
Import upstream version 1.5.0dfsg1 |
1 |
Guide to Property-Conflicts via Interactive Callback |
2 |
---------------------------------------------------- |
|
3 |
||
4 |
Basically, your conflict-callback used to be easy: for textual |
|
5 |
conflicts, {base, mine, theirs} were always defined, and {merged} was
|
|
6 |
almost always present with pre-populated conflict markers. |
|
7 |
||
8 |
Now, because we have conflicting property values, any of the four |
|
9 |
files might not exist. "mine" and "theirs" might be NULL because |
|
10 |
someone's trying to delete the property. "base" might be NULL because |
|
11 |
both parties are trying to add the same new property. |
|
12 |
||
13 |
So your conflict-callback is going to have be careful of NULL values: |
|
14 |
||
15 |
* If all three files (base, mine, theirs) are provided, then you're |
|
16 |
free to show a difference between base and merged (assuming merged |
|
17 |
is not NULL, then users will see the conflict markers). |
|
18 |
||
19 |
* If your conflict callback gets a NULL merged-file, then it means |
|
20 |
libsvn_wc did not make an attempt to merge things automatically. |
|
21 |
The conflict callback is welcome to attempt the merge itself; if it |
|
22 |
does so, then put the result in a new tmpfile somewhere and pass the |
|
23 |
path back in svn_wc_conflict_result_t->merged_file. (And don't |
|
24 |
forget to 'choose_merged' as well.) |
|
25 |
||
26 |
* If you receive a NULL base-file, this means that both agents are |
|
27 |
trying to add the property for the first time. That's fine: you can |
|
28 |
still try show a diff between the 'mine' and 'theirs' file. |
|
29 |
||
30 |
* If your conflict callback gets a NULL 'mine' or NULL 'theirs', it |
|
31 |
means that one agent is attempting to delete the property, and one |
|
32 |
is trying to modify it. Display this to your users however you |
|
33 |
wish. |
|
34 |
||
35 |
* Note that it's also possible for a property conflict to happen and |
|
36 |
your callback to *not* get called. If both agents are trying to |
|
37 |
modify and existing property, and they *disagree* on the prior base |
|
38 |
value, then there's no way to do a 3-way merge. (For example, |
|
39 |
suppose one agent is trying to change property "color" from "red" to |
|
40 |
"green", and the other agent is trying to change the same "color" |
|
41 |
property from "yellow" to "blue".) In this case, the conflict |
|
42 |
callback isn't invoked at all; the property is marked (C)onflicted |
|
43 |
and a .prej file is created to describe the contextual mismatch. |
|
44 |
||
45 |
||
46 |
||
47 |
* Hand-testing your interactive property handling (for sanity): |
|
48 |
||
49 |
- Both agents try to change an existing property, but to different values. |
|
50 |
||
51 |
-> CLI offers a diff between base and merged, to show the prop |
|
52 |
conflicts. |
|
53 |
||
54 |
- Both agents attempt to add a new property, but with different |
|
55 |
values. |
|
56 |
||
57 |
-> CLI offers a diff between mine and theirs, to show the |
|
58 |
disagreement in newly-added values. |
|
59 |
||
60 |
- One agent tries to change an existing property, other agent tries |
|
61 |
to delete it. |
|
62 |
||
63 |
-> CLI simply says, "You want to delete the prop, they want to |
|
64 |
set its value to blah." No other diff offered. |
|
65 |
||
|
1.5.2
by Peter Samuelson
Import upstream version 1.6.11dfsg |
66 |
http://svn.apache.org/repos/asf/subversion/trunk/subversion/svn/conflict-callbacks.c |
|
1.1.10
by Matthias Klose
Import upstream version 1.5.0dfsg1 |
67 |
contains the conflict resolution callback for the command-line client. |