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 New page: What's the theoretical difference between 'sync', 'reintegrate' and 'cherry-pick' merges in Subversion? == 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: {{{ (1) +- b@r2 ---- b@r3 ---- (branch) / | (merge) / v --- a@r1 -------------+- a@r4 ---- (2) --- 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 'merge-graph-v2.py'. [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. }}}
