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=5&rev2=6 Comment: More on logical changes vs commits 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 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". + + Merge tracking should treat every original commit as that kind of "logical change". This definition doesn't presuppose that every commit is *actually* relevant to every other branch in your project. If and when you want to merge this change to a branch that doesn't have a function foo() and code that calls it, then clearly you have logical conflict between the states of the two branches. This change and almost certainly a series of other changes will either be inapplicable or will need some minor or major editing to resolve the logical conflict to make them applicable. Resolving such conflicts, including omitting changes by hand that the system says logically should be merged, is a normal and expected part of merging. + + The physical manifestation of a given logical change will in general differ on different branches. In simple cases the physical manifestation will be similar: for example, the default "svn diff" output may be the same except for the line numbers. In a slightly less trivial example perhaps the context lines will also be different. And getting bit more involved, perhaps the removed "-" lines will be slightly different but the added "+" lines will be just the same. Or perhaps the diff will be just the same except in a renamed file. (Side note: Although what we mean by the physical manifestation is kind of obvious, in fact it is subtly hard to pin down, because it depends entirely how you represent the physical change. If we look at "svn diff" output, for example, differences between the source branch and the target branch in other lines of the file are hidden even though they might be important for the correctness of the patched lines.) + + It's important to consider complex examples of change. A change like adding "This is a new line" to the end of file "foo" is often too simple to demonstrate merge tracking requirements. With such an example, the tree-merge layer is quite likely to DTRT no matter what the merge tracking layer says. But important changes aren't always like that; important changes often can't be automatically merged at the tree-merge (or text-merge) level. + + IMPLEMENTATION + + Of course 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, but I view the ''purpose'' as being to track logical changes, and so when we consider cases where the two approaches require different outcomes then I look at the latter. == Merging Scenarios for Subversion 1.6 == ||||<style="text-align:center;">'''Key''' ||
