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=15&rev2=16 {{{#!wiki note This subsection describes a theoretical basis for understanding merging. It does not directly describe the behaviour of Subversion's merge tracking at the moment. }}} - Whenever I commit a change that’s not a merge, we can regard that commit as introducing a new ''logical change'' into my project, on a given branch. But when I merge that change to another branch and commit the result, that commit is not creating a new logical change, rather it is creating a new physical representation (in the target branch) of ''the same logical change''. In simple cases the physical change often looks “the same” when viewed as a diff, perhaps with the exception of line numbers and surrounding context lines. In trivial cases, such as a catch-up merge to a target branch that does not yet contain any modifications of its own, the physical change is identical. In general, however, the physical change on the target branch is necessarily different from the source branch change. It is adapted automatically (by Subversion or the user's configured 3-way merge tool) and/or manually (through ''conflict resolution''), to fit the current state of the target branch. ([[#Note_2|2]]) ([[#Note_3|3]]) The distinction between a ''commit'' and a ''logical change'' is important for merge tracking. The whole purpose of merge tracking is to decide whether to select a given change on the source branch to be merged onto the target branch or whether that logical change has already been put there. The question is about whether ''the same logical change'' is already present on the target branch. The question is not about the physical representation of that change, since we don't expect the change on the target branch to consist of exactly the same physical edits as it did in the source branch. Nor do we care whether whether the change arrived on the target branch by being merged directly from the original revision on the original branch A where that logical change was first committed to the repository, or whether it arrived in the middle of a merge of a batch of changes from branch C, if branch C received the change in a merge from branch B which was merged from branch A. When we want to merge "everything" from branch C to branch A, the merge tracking needs to be able to consider the possible changes to be merged from branch C and realize that the change at revision 130 on branch C is just a merge from branch B which was itself a merge from branch A, and thus we must not try to merge revision 130 of C to A because we already have the logical equivalents of that change in branch A. @@ -49, +48 @@ {{{#!wiki note The merge algorithm cannot possibly "know" by inspection whether the physical change that was committed as a merge is a ''faithful'' representation the set of logical changes that the mergeinfo claims it is. As far as merge tracking is concerned, if the mergeinfo says a given logical change was merged, it was merged. User interfaces should try to assist the user in understanding this. }}} - {{{#!wiki note The UI may also provide the user with a way to tell Subversion that he/she has merged a given logical change into the WC manually (not using the 'merge' command), or has merged a change into the WC and then decided to remove it before committing and not record it as merged. The command-line interface for these is "svn merge --record-only". }}} - IMPLEMENTATION The merge tracking implementation is written in terms of tracking physical changes (commits), not logical changes. In simple cases that gives exactly the same result. In particular, it gives the same result when merging from branch A to branch B if we have only ever been merging from branch A to branch B. When we introduce a third branch C, however, and wish that merge tracking would continue to work when we merge from A to B to C to A to C to B to ..., that's when we need to make the distinction. Since Subversion 1.5 (through 1.8 at least), the merge tracking stores mergeinfo ''transitively'', so after merging a change from A to B to C, the mergeinfo on branch C will list both the change on branch B that was merged directly to C, and also the change(s) in branch A that were merged directly to branch B and therefore indirectly to branch C. This partly serves to make the merge tracking act as if it is tracking logical changes. A subsequent merge from A to C will not repeat the same changes that are recorded as already merge (indirectly) from A to C, and so in that case it correctly avoids re-merging the logical changes from A that are already on C. But if we try things another way round -- first merge from A to C, and then from A to B to C, the last merge (B to C) will wrongly repeat the changes that already arrived on C in the first merge (directly from A). - == Merging Scenarios for Subversion 1.6 == + == Merging Scenarios for Subversion 1.5 through 1.7 == + + This section aims to describe the restrictions that should be observed in order for merge tracking to remain effective in Subversion 1.5 through 1.7. + - ||||<style="text-align:center;">'''Key''' || + ||||<style="text-align:center;"> || ||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 ||
