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: Wed, 18 Apr 2012 11:33:50 -0000
Message-ID: <20120418113350.13256.72222@eos.apache.org>
Subject: 
 =?utf-8?q?=5BSubversion_Wiki=5D_Update_of_=22SymmetricMerge=22_by_JulianF?=
 =?utf-8?q?oad?=
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 "SymmetricMerge" page has been changed by JulianFoad:
http://wiki.apache.org/subversion/SymmetricMerge?action=3Ddiff&rev1=3D86&re=
v2=3D87

Comment:
More criss-cross.

   * Candidate changes are { A2, A3 }.
   * Target natural history is { B1, B2, B3 }; target mergeinfo is { A1 }.
   * Notice candidate A3 can be skipped because it represents B1, as before.
-  * Merge just A2 to B.
+  * Merge "just" A2 to B.
+  * Conflict between A2 and { B1, B2 } has to be resolved.
+  * Conflict between A2 and B1 had already been resolved in the B1 -> A3 m=
erge, so this part of the user's work is repetitive.
+ =

+ The two sides of the merge are A1:A2 which we can write as { A2 }, and A1=
:B3 which represents original changes { B1, B2 }.  The conflict between A2 =
and B2 has not been resolved before, but the conflict between A2 and B1 had=
 already been resolved by the user during the merge B1->A3.
+ =

+ The conflict between A2 and B1 will be broadly the same as it was  before=
.  It will not be exactly the same, because  the conflicting hunks that wer=
e previously seen in B1 are now being seen in  state B3 where they may have=
 been modified or moved around by the subsequent changes B2 and B3.
+ =

+ The quality of the result here can be judged by how  much conflict the me=
rge encounters that the user feels should not be  necessary.  If there is a=
 lot of conflict between A2 and B1 (perhaps B1 is a big change), the user m=
ay feel that it should not be necessary to resolve that part of the conflic=
t again.   If there is little conflict between A2 and B1, resolving that ag=
ain is no big deal.
  =

  If B1 were picked as base:
  =

@@ -523, +531 @@

   * Notice candidate B1:A3 represents logical changes { A1, A2 }.  A1 is a=
lready on B; A2 isn't.  Therefore we can neither merge nor skip this change.
   * Bail out, telling the user there's a problem.
  =

- That's just like before, so the change B2 doesn't matter.
+ If O were picked as base:
+ =

+  * Candidate changes are { A1, A2, A3 }.
+  * Target natural history is { B1, B2, B3 }; target mergeinfo is { A1 }.
+  * Notice candidate A1 is already on B, and A3 represents B1, so those ca=
n be skipped.
+  * The merge would then be: base A1, source-right A2, target B4.
+ =

+ That is then the same as if we'd picked A1 as base.
  =

  =3D=3D=3D Criss-Cross #4: with unmerged logical changes on both sides =3D=
=3D=3D
  Let's try the same but with changes after the merges as well.
  =

  {{attachment:merge-criss-cross-4.png|criss-cross merge 4}}
  =

+ If A1 were picked as base:
+ =

+  * Candidate changes are { A2, A3, A4 }.
+  * Target natural history is { B1, B2, B3, B4 }; target mergeinfo is { A1=
 }.
+  * Notice candidate A3 can be skipped because it represents B1, as before.
+  * Merge just A2 to B.
  =

  =3D=3D=3D Conclusion about Criss-Cross merges =3D=3D=3D
  As noted above, I don't expect Subversion to solve criss-cross cases, at =
least I put this at a lower priority than 3-branch merge patterns.