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=9&rev2=10 ==== 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. - 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.) + 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. - 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 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 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. + 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. + + {{{#!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. + + 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". + }}} ### NEW text to be edited in: In order to make sense of this, I consider the definition of a tracked change to be:
