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=2&rev2=3 Comment: More on The Multi-Commit Merge === A Worked Example === . [TODO] - == Extension: Multiple Commits in The Same Merge == + == Extension idea: The Multi-Commit 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''. - 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. + The main benefit of linking the related commits through metadata is so that a multi-path merge (A->B, A->C, B->C) or a cyclic merge (A->B->A) can automatically include or avoid merging the follow-ups depending on whether it is including or avoiding the first commit of the group. With 1.7, the user can tell Subversion to avoid merging those follow-ups to any such branch by performing a ''record-only'' merge, but the user can only do this as and when such branches are known, not in advance. If the user does not do that record-only merge, Subversion attempts to merge those follow-ups unconditionally, and the user has to notice and edit the result (which the merge tool might or might not flag as a conflict). - 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. + (A minor benefit is it provides a standard way to annotate such follow-ups for display purposes, more formally than using comments in the log messages or other arbitrary means.) + At present, the user can emulate this concept by creating a short-lived side branch for the merge. Commit the initial result of the merge onto the branch, make multiple follow-up commits for conflict resolution and bug fixes, and then reintegrate the branch. Or, if the need for follow-up commits is not anticipated in advance, commit the original merge on its main branch, and then create a side branch from that revision as an when any follow-ups are needed. The advantage of using a side branch, rather than just committing follow-ups in head, is that the related changes are linked by metadata (through copy-history). + + Disadvantages: It would require user awareness and tool support to make use of it. I don't think that's avoidable: this isn't something that Subversion could know automatically. Anyway the current record-only merge solution requires user awareness and the tool support for it is clumsy. + + Example: 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. + - Maybe worth designing in the ability, as it (at first sight) sounds like something that could be unused and unimplemented at first and then implemented later. Until the merge algorithm pays attention to it ''and'' somebody populates it, those follow-ups B:14 and B:16 will simply be merged to C and will conflict (physically and/or semantically) just like happens today. + . ### If we design a new merge tracking model, I wonder if it would be worth designing in this capability. At first thought it sounds like something that could be unused and unimplemented at first and then implemented later. Until the merge algorithm pays attention to it ''and'' somebody populates it, those follow-ups B:14 and B:16 will simply be merged to C and will conflict (physically and/or semantically) just like happens today. . ### What are the semantics exactly? Does it matter whether A:10 is an original change or a merge? What gets complex when the merge has multiple source changes?
