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=7&rev2=8 === 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. - 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 is often “the same” but in general it is different, because it is adapted automatically or through ''conflict resolution'' to suit that target branch, or because in the target branch it is combined with other logical changes into a single commit, or both.) + 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 is often “the same” but in general it is different, because it is adapted automatically or through ''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.) This 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 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. - ### NEW text to be edited in: - In order to make sense of this, I consider the definition of a tracked change to be: - * The unit of change tracked is a logical change to the versioned tree, which was originally committed to one branch, which has a meaning or purpose that remains the same no matter which branch it ends up being merged onto. + * The unit of change tracked is a logical change to the versioned tree, which was originally committed to one branch, which has a meaning or purpose that remains the same no matter which branch it ends up being merged onto. The meaning or purpose of a logical change is typically described in the log message of the original commit. A realistic example is "Delete function foo() and change all callers to use the similar function bar() instead".
