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.

Parent-Relative Move

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

common-sense :=

follow | theirs :=

mine :=

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).

common-sense :=

follow | theirs :=

mine :=

Incoming Move F to G

common-sense | follow | theirs | mine :=

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.

Single Behaviour

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.

common-sense :=

follow :=

theirs :=

mine :=

Possible 'mine'-like actions are:

Incoming Delete Parent, Local Moved-Away Child

Incoming Delete Child, Local Moved-Away Parent

LocalMovesConflicts (last edited 2013-02-12 21:52:59 by JulianFoad)