Mailing-List: contact commits-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@subversion.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache subversion Wiki <commits@subversion.apache.org>
To: Apache subversion Wiki <commits@subversion.apache.org>
Date: Mon, 11 Feb 2013 23:04:45 -0000
Message-ID: <20130211230445.98951.52841@eos.apache.org>
Subject: 
 =?utf-8?q?=5BSubversion_Wiki=5D_Update_of_=22LocalMovesConflicts=22_by_Ju?=
 =?utf-8?q?lianFoad?=
Auto-Submitted: auto-generated

Dear Wiki user,

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

The "LocalMovesConflicts" page has been changed by JulianFoad:
http://wiki.apache.org/subversion/LocalMovesConflicts?action=3Ddiff&rev1=3D=
1&rev2=3D2

+ =3D Conflicts on Update, with Local Moves =3D
+ =

+ This is an attempt to define the desirable behaviours for all possible co=
nflicts 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 se=
nse' ones.
+ =

+ =

  '''   ''''''   ''''''   ''''''   ''''''   ''''''   '''
  ||'''Incoming ''' ||'''Local ''' ||'''Mine-full ''' ||'''Mine-c''' ||'''F=
ollow''' ||'''Theirs-c''' ||'''Theirs-full''' ||
- ||del f (not mv) ||mv f g ||A+  g (broke mv) ||=3Dmf ||||=3Dtf ||del g ||
+ ||del f (not mv) ||mv f g ||A+  g (broke mv) ||=3Dmf ||del if unmod; conf=
lict if mod ||=3Dtf ||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 || || || ||
  || || || || || || || ||
  || || || || || || || ||
  =

+ =

+ =3D=3D Incoming Delete/Move, Local Moved-Away (same node) =3D=3D
+ =

+ 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 ca=
se we have, and then we can have different behaviours.)
+ =

+ First, define the required behaviours assuming we know what kind of incom=
ing delete we have.
+ =

+ =3D=3D=3D Incoming Delete F =3D=3D=3D
+ =

+ common-sense :=3D
+   follow -- that is, delete G (though this loses evidence that there was =
a local rename)
+ =

+ follow :=3D
+   apply incoming delete to G as if 'G' were the explicit target (may rais=
e a conflict, as per standard rules for an incoming delete to a non-moved t=
arget)
+ =

+ =3D=3D=3D Incoming Move F to H =3D=3D=3D
+ =

+ common-sense :=3D
+   conflict (neither G nor H is the obvious answer in all cases)
+ =

+ follow | theirs-conflict :=3D
+   move G to H (taking the incoming move target path to be relative to the=
 parent of F)
+ =

+ =3D=3D=3D Incoming Move F to G =3D=3D=3D
+ =

+ common-sense :=3D
+   re-schedule G as non-moved; apply edits to G
+ =

+ follow :=3D
+   no-op
+ =

+ =3D=3D=3D Single Behaviour =3D=3D=3D
+ =

+ =

+ =3D=3D Incoming Delete, Local Moved-Away Child =3D=3D
+ =

+ =3D=3D Incoming Delete, Local Moved-Away Parent =3D=3D
+=20