subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <comm...@subversion.apache.org>
Subject [Subversion Wiki] Update of "LocalMovesConflicts" by JulianFoad
Date Tue, 12 Feb 2013 21:53:00 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.

The "LocalMovesConflicts" page has been changed by JulianFoad:
http://wiki.apache.org/subversion/LocalMovesConflicts?action=diff&rev1=5&rev2=6

  
  Concentrating on specifying the most useful resolutions -- the 'common sense' ones.
  
- === Move is Relative to Parent ===
+ === 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?
@@ -33, +33 @@

  
  follow | theirs :=
  
-  . 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)
  
  mine :=
  
@@ -48, +48 @@

  
  follow | theirs :=
  
-  . move G to H; merge edits
+  . move G to H (see Parent-Relative Move); re-schedule H as 'not moved'; merge edits
  
  mine :=
  
-  . re-schedule H as moved to G; 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 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.
  
  === 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
+  . 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 ==

Mime
View raw message