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=3&rev2=4 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. + + * Change C originating in trunk, is blocked from ever being merged to branch B (or if it was already merged to B, we now un-merge it and mark it at the same time). When merge from B to other branch, also "block" or remove C in same way. When we merge B to trunk (where C came from), we now un-merge C from trunk. == 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.
