Hi TC folks,
I tried to put the tree-conflicts design information so far into tables.
Find the result attached: a tc-cheatsheet up for discussion. If it gets
initial approval I'll check it into notes/tree-conflicts/ so we can edit.
(replying to Julian...)
> On Wed, 2010-02-10, Neels J Hofmeyr wrote:
>> Julian Foad wrote:
>>> Yup. And with merge, --accept=mine should be identical to 'svn revert'.
>> Hey, wait a minute. That's not true when there were local modifications
>> before the merge. I see it like this:
>
> Oh yes. Sorry for the confusion. I forgot about local mods at the moment
> I was writing that.
Phew :)
I thought I had lost it for a moment. Thanks.
[...]
[storing 'theirs' in TC-info during merge]
>> That's simple enough for a two-URL merge. But for a number of partitioned
>> revision ranges (e.g. with a --reintegrate), that may be a problem. What if
>> only the third or fiftieth revision range that is merged causes a tree
>> conflict? Does merge combine them before passing the resulting changes to
>> the merge_editor? Either case, recording or indicating those changes in
>> tree-conflict information is a tricky question on its own...
>
> I have some thoughts on this. Later.
Heh, keep the suspense up, right until the happy end (I hope) ;)
~Neels
TREE CONFLICT CHEAT SHEET (DESIGN PHASE)
After tree | 'theirs' | 'mine' is | 'svn status' shows
conflict during | is found in | found in | TC and is otherwise
-----------------+-------------------+----------------+---------------
| | |
update/switch | checked-out state | check-in state | adapted to be a
| | (unchanged) | mod of the new
| | | checked-out state
| | |
merge | conflict info | check-in state | unchanged
| | (unchanged) |
| | |
Upon recording | ... changed during |
a tree conflict, is | update/switch? | merge? |
----------------------------+----------------+----------------+
checked-out state | Yes | No |
check-in state | No | No |
'svn status' other than TC | Yes | No |
When resolving a | ...which was caused by a |
tree-conflict with | switch/update | merge |
| , the check-in state is |
----------------------+-----------------------------------+
| | |
--accept=theirs | cleared | reset to theirs |
| | |
--accept=mine | unchanged | unchanged |
| | |
'svn revert' | cleared | cleared |
| | |
<future depends-on="editor-v2" status="needs-review">
Assuming that we have full info on copy/move (i.e. an add here is really
just an add and *not* possibly part of a copy/move), then:
When resolving a |
tree-conflict of |
local vs. | incoming | offer these --accept= resolution options
===========+===========+=====================================================
| |
(all combinations of) |
add | add | theirs, mine, move-theirs, move-mine
copy-here | copy-here |
move-here | move-here |
| |
-----------+-----------+-----------------------------------------------------
| |
delete | delete | (is not a tree-conflict)
| |
-----------+-----------+-----------------------------------------------------
| |
(line-wise) |
delete | move-away | (is not a tree-conflict)
move-away | delete |
| |
-----------+-----------+-----------------------------------------------------
| |
(line-wise) |
delete | edit | theirs, mine
edit | delete |
| |
-----------+-----------+-----------------------------------------------------
| |
move-away | edit | mine, both, merge-here, merge-there,
| | merge-there-keep-here, merge-there-merge-here
| | [1] [2]
| | grain of salt ---> .
-----------+-----------+-----------------------------------------------------
| |
edit | move-away | theirs, both, merge-here, merge-there,
| | merge-there-keep-here, merge-there-merge-here
| | [1] [2]
| | grain of salt ---> .
-----------+-----------+-----------------------------------------------------
| |
move-away | move-away | theirs, mine, both, merge-at-theirs, merge-at-mine,
| | merge-at-theirs-keep-mine, merge-at-mine-keep-theirs,
| | merge-at-both
| | (not a tree-conflict when move targets match)
| | [1] [2]
| | grain of salt ---> .
-----------+-----------+-----------------------------------------------------
Where the --accept= options mean:
mine Enforce my change, make sure theirs is lost/undone.
theirs Agree to theirs, make sure mine is lost.
move-theirs Keep both additions, but move theirs to another path.
move-mine Keep both additions, but move mine to another path.
both Keep both new move-targets (one becomes a simple "A +").
merge-there Apply the edit to the moved-away path.
merge-here Discard the move-away, but still merge text/prop mods.
merge-there-keep-here Apply text/prop mods to the moved-away path, but
keep an unmerged copy at this path.
merge-there-merge-here Apply text/prop mods to the moved-away path, and
keep another, also merged, copy at this path.
merge-at-theirs Apply the edits on my moved-away path to their moved-
away path, discard my move.
merge-at-mine Apply the edits on their moved-away path to my moved-
away path, discard their move.
merge-at-theirs-keep-mine Apply the edits on my moved-away path to their moved-
away path, but keep my move-away with only *its* edits.
merge-at-mine-keep-theirs Apply the edits on their moved-away path to my moved-
away path, but keep their move-away with only *its*
edits.
merge-at-both Apply all edits to all moved-away paths and keep them.
[1] I am not sure whether resolution should only care about *this* path.
Some of the resolution options suggest that we would undo the add-part
of a move-away, at the *other* path, or apply edits to the *other* path.
While it would be nicer if we could get away with only resolving *this*
path, users might get annoyed with having to do two steps to get what
they wanted (i.e. manually modify the other path to the desired result)
when the resolver had all the information there and could have just done
the job automatically.
[2] The merge-* options indicate a mixture of text/prop mods with tree
conflicts. They say whether to keep the respective sides' text/prop mods
when resolving the tree-conflict. These options would entail that we
have to run an apply-textdelta-ish code that can introduce new text/prop
conflicts.
Should we really go there? What are the alternatives? We won't get away
without defining what happens to text/prop mods at two different paths
that are related via moves.
### Analogy to copies?
</future>
Received on 2010-02-10 14:42:12 CET