Hi!
My initial thought when I started writing on a spec for a TC resolver
was that it would involve a lot of quirks and edge cases handled solely
in subversion/svn/conflict-callbacks.c. That the svn resolver would only
serve as a proof-of-concept for other API users. But if I could
implement the ---accept options in libsvn_wc/conflicts.c we would have a
firm foundation for others to build upon.
I could implement each --accept option in libsvn_wc/conflicts.c and
write test cases for each. Is this a possible way to go? Many of the
--accept options would require much more than the existing ones for
property and text conflicts.
What to do?
============
Finish the resolver spec of course.
Make svn resolved able to handle states other than 'working'
|-> We need to store the tree conflict data on the same node instead of
| its parent.
|-> Things would be cleaner if we stored the different versions of a
node in the db instead of temp files.
Daniel
On Wed, Feb 10, 2010 at 02:41:29PM +0100, Neels J Hofmeyr wrote:
> 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.
>
> 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>
>
