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 17:54:26 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=3&rev2=4

+ ''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.
  
+ === Move is Relative to Parent ===
+ 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 ''' ||'''Local ''' ||'''Mine-full ''' ||'''Mine-c''' ||'''Follow''' ||'''Theirs-c'''
||'''Theirs-full''' ||
- ||del f (not mv) ||mv f g ||A+  g (broke mv) ||=mf ||del if unmod; conflict if mod ||=tf
||del g ||
- ||(f mv-to h) || ||h mv-to g; only my mods ||h mov-to g; merge mods || || || ||
- ||(f mv-to g) || ||g; only my mods ||g; merge mods || || || ||
- || || || || || || || ||
- || || || || || || || ||
- 
  
  == Incoming Delete/Move, Local Moved-Away (same node) ==
- 
  Incoming: delete F or move-away F
  
  Local: F moved-to G
@@ -27, +27 @@

  First, define the required behaviours assuming we know what kind of incoming delete we have.
  
  === Incoming Delete F ===
+ common-sense :=
  
- common-sense :=
-   follow (though this loses evidence that there was a local rename)
+  . follow (though this loses evidence that there was a local rename)
  
  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)
+  . 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)
  
  mine :=
+ 
-   re-schedule G as copied from old F
+  . re-schedule G as copied from old F
  
  === Incoming Move F to H ===
+ common-sense :=
  
- common-sense :=
-   conflict (neither G nor H is the obvious answer in all cases)
+  . conflict (neither G nor H is the obvious answer in all cases)
  
  follow | theirs :=
-   move G to H; merge edits (taking the incoming path H as relative to the parent of F and
G)
+ 
+  . move G to H; merge edits
  
  mine :=
+ 
-   re-schedule H as moved to G; merge edits
+  . re-schedule H as moved to G; merge edits
  
  === Incoming Move F to G ===
+ common-sense | follow | theirs | mine :=
  
- common-sense | follow | theirs | mine :=
-   re-schedule G as non-moved; merge edits
+  . re-schedule G as non-moved; merge edits
  
  === Single Behaviour ===
+ == Incoming Delete Parent, Local Moved-Away Child ==
+ == Incoming Delete Child, Local Moved-Away Parent ==
  
- 
- == Incoming Delete, Local Moved-Away Child ==
- 
- == Incoming Delete, Local Moved-Away Parent ==
- 

Mime
View raw message