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 Mon, 11 Feb 2013 23:04:45 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=1&rev2=2

+ = 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.
+ 
+ 
  '''   ''''''   ''''''   ''''''   ''''''   ''''''   '''
  ||'''Incoming ''' ||'''Local ''' ||'''Mine-full ''' ||'''Mine-c''' ||'''Follow''' ||'''Theirs-c'''
||'''Theirs-full''' ||
- ||del f (not mv) ||mv f g ||A+  g (broke mv) ||=mf ||||=tf ||del g ||
+ ||del f (not mv) ||mv f g ||A+  g (broke mv) ||=mf ||del if unmod; conflict if mod ||=tf
||del g ||
- ||(mv to h) || || || || || || ||
- ||(mv to 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
+ 
+ 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 -- that is, delete G (though this loses evidence that there was a local rename)
+ 
+ follow :=
+   apply incoming delete to G as if 'G' were the explicit target (may raise a conflict, as
per standard rules for an incoming delete to a non-moved target)
+ 
+ === Incoming Move F to H ===
+ 
+ common-sense :=
+   conflict (neither G nor H is the obvious answer in all cases)
+ 
+ follow | theirs-conflict :=
+   move G to H (taking the incoming move target path to be relative to the parent of F)
+ 
+ === Incoming Move F to G ===
+ 
+ common-sense :=
+   re-schedule G as non-moved; apply edits to G
+ 
+ follow :=
+   no-op
+ 
+ === Single Behaviour ===
+ 
+ 
+ == Incoming Delete, Local Moved-Away Child ==
+ 
+ == Incoming Delete, Local Moved-Away Parent ==
+ 

Mime
View raw message