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=13&rev2=14 Comment: Wording improvements === Identifying Logical Changes vs. Commits === ==== and Why Conflict Resolution is Part of Merging ==== - 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. + 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''. - When I commit a change that’s not a merge, we can regard that 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 is not creating a new logical change, rather it is the physical representation in that target branch of the same logical change. In simple cases the physical change often looks “the same”, when viewed as the ouput of a typical diff program if you ignore line numbers, but in general the physical change is necessarily different because it is adapted (automatically by the user's chosen 3-way merge helper, and/or through manual ''conflict resolution'') to suit that target branch, or because in the target branch it is combined with other logical changes that are merged at the same time into a single commit, or both. + 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]]) The distinction between a ''commit'' and a ''logical change'' is important in an automatic merge, when we want to avoid merging any ''logical change'' that is already present on the target branch, no matter from which intermediate branch it arrived there. - 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 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, 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. {{{#!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. The user interfaces should assist the user in understanding this. @@ -148, +148 @@ === Note 1 === Other possible kinds of merging include taking any arbitrary difference between two files or directories -- perhaps on different branches or without any branching history connecting them -- and merge that difference into some other file or directory (perhaps unrelated to either side of that diff). Merge tracking does not try to address such cases, and so we do not consider them here. + === Note 2 === + If this change is being merged into a target WC in which other changes have also being merged, and touches some of the same nodes, then similarly this change is also adapted (automatically and/or through manual conflict resolution) to combine with those other changes. +
