Differences between revisions 5 and 6
Revision 5 as of 2013-02-12 18:45:02
Size: 2818
Editor: JulianFoad
Comment:
Revision 6 as of 2013-02-12 21:52:59
Size: 3460
Editor: JulianFoad
Comment:
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
=== Move is Relative to Parent === === Parent-Relative Move ===
Line 34: Line 34:
 . apply the delete to G as if G were the explicit target (may raise a conflict, as per standard rules for a non-moved target)  . delete G (just as if G were the explicit target of the incoming delete; thus, may raise a conflict)
Line 49: Line 49:
 . move G to H; merge edits  . move G to H (see Parent-Relative Move); re-schedule H as 'not moved'; merge edits
Line 53: Line 53:
 . re-schedule H as moved to G; merge edits  . re-schedule as 'H moved to G'; merge edits
Line 58: Line 58:
 . re-schedule G as non-moved; merge edits  . 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.
Line 61: Line 63:
The single behaviour is what we have to do when we don't know whether the incoming delete is part of a move.
Line 65: Line 69:
 tree-conflict  . tree-conflict
Line 69: Line 73:
 ??  . ??
Line 73: Line 77:
 ??  . ??
Line 77: Line 81:
 ??  . ??

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)

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

mine :=

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

common-sense :=

  • tree-conflict

follow | theirs :=

  • move G to H (see Parent-Relative Move); re-schedule H as 'not moved'; merge edits

mine :=

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

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 :=

  • tree-conflict

follow :=

  • ??

theirs :=

  • ??

mine :=

  • ??

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

Incoming Delete Child, Local Moved-Away Parent

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