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, 06 Feb 2012 13:04:24 -0000
Message-ID: <20120206130424.6866.45605@eos.apache.org>
Subject: 
 =?utf-8?q?=5BSubversion_Wiki=5D_Update_of_=22SvnMergeTheory=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 "SvnMergeTheory" page has been changed by JulianFoad:
http://wiki.apache.org/subversion/SvnMergeTheory?action=3Ddiff&rev1=3D15&re=
v2=3D16

   * For the 3-way merge, Subversion selects a base node that is on the ''t=
arget'' branch rather than on the ''source'' branch.
   * For the mergeinfo, Subversion records all the changes along the source=
 branch (B), starting from 'O'.
  =

- It is interesting to consider the meaning of the mergeinfo that is record=
ed.  The mergeinfo added to branch A in change A5 says that all the changes=
 along branch B have been merged which, loosely speaking, is correct.  But =
if we look carefully, that does not accurately descibe the set of ''logical=
 changes'' that have been merged, because B3 was not a new logical change i=
ntroduced on branch B.  B3 (if viewed as a change on B``) was the merging i=
nto B of changes A1 and A2, and we haven't tried to merge those back onto A=
; instead we've carefully chosen a 3-way merge that avoided trying to re-ap=
ply them to A and just merged the ''other'' changes from B.
+ It is interesting to consider the meaning of the mergeinfo that is record=
ed.  The mergeinfo added to branch A in change A5 says that all the changes=
 along branch B have been merged which, loosely speaking, is correct.  But =
if we look carefully, that does not accurately descibe the set of ''logical=
 changes'' that have been merged, because B3 was not a new logical change i=
ntroduced on branch B.  B3 (if viewed as a change on B) was the merging int=
o B of changes A1 and A2, and we haven't tried to merge those back onto A; =
instead we've carefully chosen a 3-way merge that avoided trying to re-appl=
y them to A and just merged the ''other'' changes from B.
  =

  More significantly, neither does the mergeinfo "B:1-4" accurately describ=
e the set of ''physical changes'' that were merged.  The physical (3-way) m=
erge took the difference between A2 and B4, which we can describe as A2:B3 =
followed by B3:B4.  The second part (B3:B4) we can descibe in mergeinfo syn=
tax as "B:4".  The first part, A2:B3, we can't describe using mergeinfo syn=
tax.  Logically it's equivalent to changes B1 and B2, but it's not physical=
ly the same, because A2:B3 is the rewriting of B1 and B2 into the context o=
f branch A.  (See ''The Two Sides of a Merge'', below, for clarification.)
  =

- Those are the cases that Subversion 1.7 supports.  Now, what ''could'' we=
 support?
+ Those are the basic cases that Subversion 1.7 supports.
+ =

+ TODO: How sync works after a reintegrate.
+ =

+ TODO: How Subversion handles cherry-picks in the direction of sync merges.
+ =

+ Same dir'n -- svn succeeds.  Opposite dir'n -- svn fails.
+ =

+ TODO: How a record-only merge ("keep-alive dance") enables another reinte=
grate to work.
+ =

+ =3D=3D Unifying Sync and Reintegrate =3D=3D
  =

  =3D=3D Cherry pick: 3-way or 4-way Merge =3D=3D
  Subversion currently performs any requested merge as a sequence of 3-way =
merges.  For simple ''sync'' and ''reintegrate'' merges, that's exactly wha=
t's needed.  Usually there is just one 3-way merge, but if cherry-picks are=
 being skipped then Subversion breaks down the merge source range into sub-=
ranges and performs one 3-way merge per sub-range.