subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <>
Subject [Subversion Wiki] Update of "SvnMergeTheory" by JulianFoad
Date Mon, 30 Jan 2012 17:44:18 GMT
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:

New page:
What's the theoretical difference between 'sync', 'reintegrate' and 'cherry-pick' merges in

== Playing catch-up with Sync and Reintegrate ==

Brane wrote:

When you create a branch, the origin of the branch is an interesting bit of information. However,
for merging, it is entirely irrelevant if branch A was created from B or the other way around.
To illustrate:

               +- b@r2 ---- b@r3 ----
     (branch) /              | (merge)
             /               v
       --- a@r1 -------------+- a@r4 ----

       --- a@r1 ----------- a@r3 ----
             \               | (merge)
     (branch) \              v
               +- b@r2 ------+- b@r4 ----

Cases (1) and (2) are exactly equivalent as far as the merge algorithm
is concerned, but Subversion calls the first a reintegrate merge and the
second a sync merge, and treats them differently, as if branch (a) were
somehow special. It's not.
-- Brane

{{attachment:merge-sync-1-req.png|basic sync merges}}

== 3-way merge ==

{{{#!wiki comment

Subversion performs a requested merge as a sequence of 3-way merges.  For example, in a simple
'sync' merge such as the second one in <merge-sync-1-req.png> [1], Subversion determines
that all the source changes up to A2 are already merged, so the source side of the merge is
changes A2:A4 (aka A:3-4 in mergeinfo syntax), as shown in <merge-sync-1-svn.png>. 
On that diagram, the arcs that start with a circle and end with a T-shaped bar represent the
span of the source side of the merge.

What Subversion actually does is it looks along the (direct) history of the source branch
(A), and finds the first contiguous range of revisions along the history of A that haven't

ClearCase would perform this 'sync' merge exactly the same way, but it would determine what

Now look at a simple reintegrate scenario <merge-reint-1.png>.

I believe you're quite right in saying that our reintegrate and sync merges are restricted
versions of a single general merge, iff we're talking about merging patterns that consist
only of sync and reintegrate merges.

Remember that ClearCase doesn't track cherry-pick merges [2]. 

Branko ─îibej wrote:

[Re. the difference between "reintegrate" and "sync" merges]
> [...] This looks like someone /started off/ with the assumption that
> a sync merge can take shortcuts where a reintegrate merge cannot;

The assumption is that the sync merge is one special case of merging and so can take one set
of shortcuts, while the reintegrate is another special case and can take a different approach
with its own set of restrictions and short-cuts.

> but, so sorry, that's just plain nonsense. The
> cases are exactly symmetrical, all edge cases apply to both directions
> of the merge, a sync merge can encounter all the complications of a
> reintegrate merge.

Yes, if our model of merging is

  [1] I've just been writing a merge graph drawing program to help produce diagrams like this.
Attached as ''.

  [2] ClearCase can perform a cherry-pick merge, and may even be able to record some metadata
about it, but (as far as I can discover) the merge algorithm doesn't take account of cherry
picks when working out what needs to be merged.  Git is similar; from what I read recently
it has an extension that can perform a cherry-pick merges and  store cherry-pick metadata
somewhere and use it to track cherry picks when using that extension -- but the metadata is
completely separate from the fundamental merge DAG, and AFAIK the standard merges don't recognize
and account for cherry picks.


View raw message