Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "MergeTrackingIdeas" page has been changed by JulianFoad: http://wiki.apache.org/subversion/MergeTrackingIdeas?action=diff&rev1=1&rev2=2 Comment: Tweaks to 'Multiple commits in same merge' * User-facing goals defined in terms of merging the right set of ''logical changes''. * Each commit is either a ''logical change'' or a ''merge'' of ''logical changes''. - We introduce the concept of a ''logical change'' as the fundamental unit of change that is tracked. A ''logical change'' starts life as a committed change that is not part of a merge. When that tree-content change is merged to another branch (adapted if necessary to accommodate any physical and/or semantic differences between the branches), the resulting commit is ''not'' a new ''logical change'' but rather is a ''merge''. A ''merge'' is defined as a committed change that includes a mergeinfo change that brings in one or more ''logical changes''. A ''logical change'' has a unique identifier (let’s say the branch and revision in which it was originally committed) and is always identified by that same identifier, no matter what branches it has been merged through or whether it has been merged together with other ''logical changes'' in a single ''merge''. + We introduce the concept of a ''logical change'' as the fundamental unit of change that is tracked. A ''logical change'' starts life as a committed change that is not part of a merge. When that tree-content change is merged to another branch (adapted if necessary to accommodate any physical and/or semantic differences between the branches), the resulting commit is ''not'' a new ''logical change'' but rather is a ''merge''. A ''merge'' is defined as a committed change that includes a mergeinfo change that brings in one or more ''logical changes''. + + A ''logical change'' has a unique identifier (let’s say the branch and revision in which it was originally committed) and is always identified by that same identifier, no matter what branches it has been merged through or whether it has been merged together with other ''logical changes'' in a single ''merge''. We must be able to identify the ''logical changes'' in the system. To identify the ''logical changes ''in existing 1.6 mergeinfo, we will classify each commit as a ''logical change'' if it is a change without any mergeinfo change, or else as a ''merge'' if it includes a mergeinfo change. If it’s ''merge'', then it brings in some pre-existing logical changes and/or merges. By scanning recursively into mergeinfo history, we can identify all the original logical changes brought in by a merge. @@ -67, +69 @@ * Quick(ish) traversal of mergeinfo history. This suggests a new storage model in which all the historic mergeinfo (of a given branch?) is in one place. === A Worked Example === - == Multiple Commits in One Logical Change == + . [TODO] + + == Extension: Multiple Commits in The Same Merge == + We might want to allow multiple revisions to be recorded as being components of the same ''merge''. For example, sometimes a user will choose to commit the initial result of a merge first, and then do further conflict resolution and commit again. Without this extension, the first of these commits would be tracked as a ''merge'', and the second would wrongly be classified as a new ''logical change''. We could design a way to be able to track these two commits as a single logical ''merge''. + - We might want to allow multiple revisions to be recorded as being components of the same ''merge''. This would increase the power of merge tracking in a functional sense, but it is “advanced” functionality and would require user awareness and tool support to make use of it. + This would increase the power of merge tracking in a functional sense, but it is “advanced” functionality and would require user awareness and tool support to make use of it. Merge A:10 to B, committing the result initially as B:13, then doing some more conflict resolution in B:14 and B:16. Arrange somehow (by user input, for example) for B:14 and B:16 also to be recorded as part of the “same” merge: branch B revs 13, 14, 16 jointly comprise the merge of A:10. In a subsequent merge from B to C, assuming A:10 is already on C, that would prevent B:13, B:14 and B:16 from being merged to C.
