This page is under construction.
Conflicts on Update, with Local Moves
This is an attempt to define the desirable behaviours for all possible conflicts involving an incoming change on update or switch and a local move. Initially the long-term desired behaviour is specified; the immediate goal for 1.8 is (or will be) then specified.
Concentrating on specifying the most useful resolutions -- the 'common sense' ones.
Sometimes, especially when combining two moves, we need to interpret a move of (say) A/F to A/H as being a move relative to its parent (in this case, A) so that if the parent itself has been moved (A to A2) we don't try to interpret the destination of F as the absolute path A/H but rather as A2/H. That works for a move where the node stays in the same parent directory.
When A/F moves deeper inside its parent directory (to A/B/F), then what?
When A/F moves outside its parent directory (to A2/F), then what?
Incoming Delete/Move, Local Moved-Away (same node)
Incoming: delete F or move-away F
Local: F moved-to G
One tricky issue is to select a single behaviour such that all sub-cases (the incoming delete may be part of a move) are handled OK without knowing which case we have. (The alternative is to heuristically discover which case we have, and then we can have different behaviours.)
First, define the required behaviours assuming we know what kind of incoming delete we have.
Incoming Delete F
- follow (though this loses evidence that there was a local rename)
follow | theirs :=
- delete G (just as if G were the explicit target of the incoming delete; thus, may raise a conflict)
- re-schedule G as copied from old F
Incoming Move F to H
Neither G nor H is the obvious final destination in all cases. In all cases, it makes sense to merge the edits (but we might need to defer that until the final destination is chosen).
follow | theirs :=
- move G to H (see Parent-Relative Move); re-schedule H as 'not moved'; merge edits
- re-schedule as 'H moved to G'; merge edits
Incoming Move F to G
common-sense | follow | theirs | mine :=
- re-schedule G as 'not moved'; merge edits
Note: This is a degenerate case of "Incoming Move F to H". Most of the required special-casing should be handled within the "move G to H; re-schedule H as 'not moved'" action; only the decision whether to raise a tree conflict or auto-resolve should need to be coded at this level.
The single behaviour is what we have to do when we don't know whether the incoming delete is part of a move.
These scenarios are all genuine tree conflicts (meaning there is no single "obvious" intention as there is with an "edit onto moved" scenario), and typically infrequent, so raising a conflict by default is satisfactory.
Possible 'mine'-like actions are:
- re-schedule G as copied from old F (if no incoming node copied from old-F)
- re-schedule G as moved from H; merge edits (if incoming node H copied from old-F)
Incoming Delete Parent, Local Moved-Away Child