Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "SupportedMergeScenarios" page has been changed by JulianFoad: http://wiki.apache.org/subversion/SupportedMergeScenarios?action=diff&rev1=4&rev2=5 Comment: Write about merge tracking vs merging = What Merges Does Svn’s Merge Tracking Support? = We need to be able to say, “If you do all your merging like <this>, it will work like you expect.” So what is <this>? What are the supported scenarios, limitations and rules, and what can the user expect within and outside those scenarios? + The information in this document is not intended to repeat the functional documentation of the “merge” command itself, but rather to explain the ways in which that command can be used effectively. + + === Merge Tracking vs. Merging === Merging is a broad term. We’re talking here about here merging changes that have been made on one branch into another branch. The whole process of merging includes several steps which may be manual or automated: * selecting a source branch @@ -15, +18 @@ * committing the result * possibly other actions such as deleting the source branch if it is finished with, or taking action to “keep it alive” after a reintegrate - This document is concerned primarily with merging in such a way that Subversion’s merge ''tracking'' will enable future automatic (''catch-up'' and ''reintegrate) ''merges to select the correct set of changes. This answers the question, “What ''logical changes'' don't I have on branch B already, that I need to pull from branch A to B?” A related but different issue is how to apply those changes to the target branch: “For a given physical or logical change ‘c1’ that branch A claims to have an instance of, how do I construct from ‘c1’ the best physical edit that will apply to branch B with the least amount of spurious physical conflict?” + Merge tracking is a mechanism by which Subversion remembers which changes you've merged from one branch to another and uses this information to honour a request to merge "all the unmerged changes" from one branch to another. Merge tracking is about deciding which changes to merge, and about recording which changes have been merged. As far as merge tracking is concerned, a "change" means the change that was committed in a particular revision to a particular node or tree. - The information in this document is not intended to repeat the functional documentation of the “merge” command itself, but rather to explain the ways in which that command can be used effectively. + A related but different issue is how to apply the selected changes to the target branch. The task of applying the changes to the target working copy can be called tree-merging: that is, taking a diff between two trees and applying this diff, node-wise and text-wise, to a third tree. We could say: “For a given physical or logical change ‘c1’ that branch A claims to have an instance of, how do I construct from ‘c1’ the best physical edit that will apply to branch B with the least amount of spurious physical conflict?” For this task we currently use a built-in algortithm on the tree structure level, and a three-way merge algorithm on the file-content of text files. + + So merge tracking is a layer on top of tree-merging, with a clear separation of tasks. + + This document is concerned primarily with the kinds of merges in which Subversion’s merge ''tracking'' takes effect -- that is the automatic (''catch-up'' and ''reintegrate) ''merges. === Identifying Logical Changes vs. Commits === To discuss the nuances of what exactly is tracked in Merge Tracking, we need to think about the difference between a raw change in the repository (a ''commit'') and a concept that we can call a ''logical change''. This distinction is ''not'' implemented in Subversion 1.6. @@ -29, +36 @@ The whole subject of merge tracking is about whether to port the a given ''logical change'' onto the target branch, or whether that ''logical change'' has already been put there. The question is not about the physical representation of that change; it doesn’t matter whether the change was achieved on the target branch by exactly the same physical edits as it was in the source branch. The merge algorithm cannot possibly know whether the physical change that was committed (at the time when the merge info says the merge happened) accurately represents the ''logical change'' that is claimed, but if it doesn’t (or indeed if it is totally unrelated), then something has gone wrong at a higher level. As far as ''merge tracking'' is concerned, that change was merged. == Merging Scenarios for Subversion 1.6 == - ||||<style="text-align: center;">'''Key''' || + ||||<style="text-align:center;">'''Key''' || ||A, B, C, … ||branches || ||A:3 ||the change in branch A that was committed as revision 3 || ||A ⇒ B ||a high-level relationship assumed between branches A and B, in the indicated direction ||
