Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "SvnMergeTheory" page has been changed by JulianFoad: http://wiki.apache.org/subversion/SvnMergeTheory?action=diff&rev1=45&rev2=46 == Cherry-pick Merges == A ''cherry-pick'' merge, for our purposes here, is one that takes from the source branch a change that is ''not'' the first unmerged change, thus leaving an "gap" of unmerged changes between sequences of merged changes. By contrast, a ''complete'' merge (a ''sync'' or a ''reintegrate'') ensures that all source changes up to and including the specified one are merged to the target. + We are not going to discuss here ''how'' a cherry-pick merge is performed. (See FourWayCherryPick for an interesting side note about that.) Instead we are concerned with how a complete merge will account for any changes that have already been merged by cherry-picking. + If a cherry-pick merge has occurred since the last complete (sync or reintegrate) merge, the next complete merge should, loosely speaking, skip it. We can classify such a cherry-pick by its position and direction with respect to the last complete merge: {{attachment:merge-cherry-kind1.png|cherry-pick kind 1}} @@ -220, +222 @@ == The Two Sides of a Merge == TODO: Explain the idea that the result of a 3-way merge from branch A to B, committed as B3, can be seen either as a change on B consisting of the addition of some stuff from A, or can be seen equally validly as the change A2:B3 consisting of the merging of recent changes on B into the context of A. The fact that the result was committed on branch B does not matter; the same result could have been committed on branch A, or on both branches. - == Cherry pick: 3-way or 4-way Merge == - Subversion currently performs any requested merge as a sequence of 3-way merges. For simple ''sync'' and ''reintegrate'' merges, that's exactly what'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. - - For a ''cherry-pick'' merge, a 3-way merge is not quite right: - - {{attachment:merge-cherry-3way.png|Cherry-Pick as 3-way Merge}} - - ... because it tries to merge the change A2:A3 (so far, so good) with the change A2:B3. The trouble is that the latter diff includes not only changes that were made deliberately in B, such as B3, but also the ''reverse'' of some changes that were made earlier in A, specifically A2 and A1. In simple cases that works fine, but we could do better. [TODO: Describe what goes wrong with it. Is it more chance of conflicts? Is http://svn.haxx.se/users/archive-2011-10/0834.shtml a concrete example?] - - A [[http://svn.apache.org/repos/asf/subversion/trunk/notes/variance-adjusted-patching.html|4-way merge]] would be more correct: - - {{attachment:merge-cherry-4way.png|Cherry-Pick as 4-way Merge}} - == Terminology == complete merge:: A merge that merges all the changes from the source branch that have not yet been merged into the target. A ''sync'' merge and a ''reintegrate'' merge and a ''symmetric'' merge are all ''complete'' merges. - symmetric merge:: A ''complete merge'' that works in either direction between two branches, no matter which branch is regarded as the parent and which as the child, and no matter which direction any previous merges between those branches were performed. A ''complete merge'' is the normal kind of merge in systems such as ClearCase; this paper is about developing such a merge in Subversion. == Drawing The Graphs ==
