Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "MergeDev/MergeTheoryTopics" page has been changed by JulianFoad: http://wiki.apache.org/subversion/MergeDev/MergeTheoryTopics?action=diff&rev1=2&rev2=3 ~-''This is not part of the official documentation of Subversion. It is aimed at the developers of Subversion, and may not reflect reality or the project community's plans. For official documentation, see'' http://subversion.apache.org/docs/ ''.''-~ ---- + The aim of this page is to hold initial design notes and ideas on all of the topics relevant to the theory of merge tracking, in the context of enhancing merge support in Subversion after 1.8. It does not aim to comprehensively cover each topic. - The aim of this page is to hold initial design notes and ideas on all of the topics - relevant to the theory of merge tracking, in the context of enhancing merge support - in Subversion after 1.8. It does not aim to comprehensively cover each topic. - == Per Node or Per Tree Semantics == + A 'branch' consists of a set of nodes at any given time, but the set of nodes is not fixed, it varies over time. Nodes can be added and deleted. (Can a node be moved into or out of a branch? What does it mean?) + Therefore, asking 'what changes have been made on branch A?' involves more than querying merge history for each node that is *currently* on branch A. - A 'branch' consists of a set of nodes at any given time, but the set of - nodes is not fixed, it varies over time. Nodes can be added and deleted. - (Can a node be moved into or out of a branch? What does it mean?) - - Therefore, asking 'what changes have been made on branch A?' involves more - than querying merge history for each node that is *currently* on branch A. - == Relationships Between Branches == + . "As soon as the relationship between branches ceases to be a tree, it becomes impossible for users to understand what's going on. [...] I'm in favor of the version control system not allowing you to do goofy things, and keep track of the coherent relationships between branches" - - "As soon as the relationship between branches ceases to be a tree, it - becomes impossible for users to understand what's going on. [...] I'm in - favor of the version control system not allowing you to do goofy things, - and keep track of the coherent relationships between branches" - -- Bram Cohen. + . -- Bram Cohen. + [A VCS should] have the shadowing concept be built in from the ground up. And allow the safe forms of reparenting. And make sure that the branch relationships and their changes are kept in the history along with everything else. - - [A VCS should] have the shadowing concept be built in from the ground up. - And allow the safe forms of reparenting. And make sure that the branch - relationships and their changes are kept in the history along with - everything else. - -- "Version Control Recommended Practices" (point 9), Bram Cohen + . -- "Version Control Recommended Practices" (point 9), Bram Cohen See Perforce's "Merge Down, Copy Up". - See Perforce's "Streams". Stream types: mainline, development, release. + See Perforce's "Streams". Stream types: mainline, development, release. Stream policies: "merge down, copy up". - Stream policies: "merge down, copy up". Does Mercurial have something towards this? - == Fast-Forward == - Fast-forward merge should: - * Ensure minimal changes are sent to/from a WC. + * Ensure minimal changes are sent to/from a WC. - * Leave merge history that clearly shows no changes were committed + * Leave merge history that clearly shows no changes were committed - but the target was simply rebased. + . but the target was simply rebased. - == Unrelated Changes == - Theory of committing an unrelated change along with a merge. + I think, to make sense of arbitrary merging across multiple branches, unrelated changes should not be supported. (They should be seen as part of conflict resolution.) Then, changes can be merged physically from any convenient branch in the graph. If an unrelated change is required to be "tracked" (treated as a logical change that must be merged to the target branch), then all required changes in a merge have to come physically from the specified source branch. - I think, to make sense of arbitrary merging across multiple branches, - unrelated changes should not be supported. (They should be seen as part of - conflict resolution.) Then, changes can be merged physically from any - convenient branch in the graph. If an unrelated change is required to be - "tracked" (treated as a logical change that must be merged to the target - branch), then all required changes in a merge have to come physically from - the specified source branch. + Doug Robinson said, for criss-cross, we must assume user may have committed an unrelated change each time, and therefore the two branches cannot be considered equivalent until either a complete merge is done one way or the user explicitly tells the VCS that the branches are equivalent. - Doug Robinson said, for criss-cross, we must assume user may have committed - an unrelated change each time, and therefore the two branches cannot be - considered equivalent until either a complete merge is done one way or the - user explicitly tells the VCS that the branches are equivalent. - - == Cherry-Pick == - Theory of tracking cherry-pick merges as well as full merges. + == Subtrees == + From [NewMerge]: "If you want to work on a subtree, you can make a new branch [...] that contains the subtree. We can track its relationship and merge it back to the complete tree." - == Subtrees == + == Merge Each Rev-Range or Merge Each File? == + Presently, Svn breaks a multi-rev-range merge into rev ranges, and the outer loop is over those ranges. An alternative is for the outer loop to be over the nodes. Advantages: splitting the merge of a single node into sub-ranges can produce spurious conflicts; merging each file in as few sub-ranges as possible avoids this. + Discussed in (one of my Wiki pages on Merge, I think) and (an old dev@ email, from Daniel Rall?). - From [NewMerge]: "If you want to work on a subtree, you can make a new - branch [...] that contains the subtree. We can track its relationship and - merge it back to the complete tree." + An additional option is to merge each file according to its own merge graph, by which I really mean choosing a merge base in the node's own graph, which, if the node has had its own subtree merging, might not be where the branch root's base is. Is such a merge semantically the same as if it were done according to the branch root's merge graph? I'm thinking of the semantic subtleties such as whether unrelated changes are propagated as expected, and how reverse-merges and blocked merges are handled. + + If we merge each tree according to its own graph (and if that has different semantics from merging them all using the branch root's graph), then that means we are treating each node the same as each other node, with no special treatment of a branch root. That may or may not be a Good Thing. That is a characteristic of file-based VCS's. + + == Reverse Merge, Blocked Merge == + Idea of differentiating between "un-merging" and "blocking" changes. They have different semantics: + + * If an original change 'C' was previously merged into branch 'B', then un-merging C from B means temporarily removing C from B. (Physically, this could be done by reverse-mergeing either the original change C or, if it was merged in to B on its own, by revers-merging the commit on B that merged it in.) The change C will be eligible for merging into B again. When merging from B to another branch, the combination of merging and un-merging change C will be considered as if C had never been merged into B. + * If an original change 'C' is *not* currently on branch B, then blocking C from B means marking B such that C will never be automatically merged into B. In that sense, it is like a record-only merge, but it should be possible to mark it in the history as a "blocking" merge. The semantics when merging from B to another branch should probably be: you're not going to get change C from me, but I'm not going to tell you anything about C; in that sense, it it *unlike* a record-only merge. + + == Continue after Conflicts? == + Can Svn do more to enable merging to continue after hitting conflicts? Presently it stops at the end of whichever revision range it is processing. == References == - * Subversion Wiki, Julian Foad, + . http://wiki.apache.org/subversion/SymmetricMerge http://wiki.apache.org/subversion/SupportedMergeScenarios - - http://wiki.apache.org/subversion/SymmetricMerge - - http://wiki.apache.org/subversion/SupportedMergeScenarios * "NewMerge", Assembla, - - http://blog.assembla.com/assemblablog/tabid/12618/bid/58122/It-s-Time-to-Fix-Subversion-Merge.aspx + . http://blog.assembla.com/assemblablog/tabid/12618/bid/58122/It-s-Time-to-Fix-Subversion-Merge.aspx * "version control tidbits", Bram Cohen, - - http://bramcohen.livejournal.com/64012.html + . http://bramcohen.livejournal.com/64012.html * "Git Can't Be Made Consistent", Bram Cohen, - - http://bramcohen.livejournal.com/74462.html + . http://bramcohen.livejournal.com/74462.html * "Rebasing", Bram Cohen, - - http://bramcohen.livejournal.com/73625.html + . http://bramcohen.livejournal.com/73625.html * "Version Control Recommended Practices" (point 9), Bram Cohen, - - http://bramcohen.livejournal.com/52148.html + . http://bramcohen.livejournal.com/52148.html * "Stream Types", Perforce, - - http://www.perforce.com/perforce/doc.current/manuals/p4guide/06_codemgmt.html#1082844 + . http://www.perforce.com/perforce/doc.current/manuals/p4guide/06_codemgmt.html#1082844 * "CM Research Papers and Experience Reports", Brad Appleton, - - http://www.bradapp.com/links/scm-links.html#CM_Res_Paps_Exp_Reps + . http://www.bradapp.com/links/scm-links.html#CM_Res_Paps_Exp_Reps * "Using git fast-forward merging to keep branches in sync", - - http://nathaniel.themccallums.org/2010/10/18/using-git-fast-forward-merging-to-keep-branches-in-sync/ + . http://nathaniel.themccallums.org/2010/10/18/using-git-fast-forward-merging-to-keep-branches-in-sync/ * "MarkMerge", - - http://wiki.monotone.ca/MarkMerge/ + . http://wiki.monotone.ca/MarkMerge/ ---- - ~-''This page was written initially by JulianFoad and may be edited by others.''=~ + ~-''This page was written initially by JulianFoad and may be edited by others.''=~ -~
