Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "SymmetricMerge" page has been changed by JulianFoad: http://wiki.apache.org/subversion/SymmetricMerge?action=diff&rev1=92&rev2=93 Comment: Add a 'User perspective' section Can we define the base-choosing algorithm so that it always picks the "good" base when there is one? The last rev on A synced to B is A1, and the last rev on B synced to A is B1. Normally, we'd expect either B1 to be >= the target of the A1->B merge, or vice versa. But neither is the case here; that's more or less what defines this as a criss-cross. There's something special going on, so the presence of change A2 makes a base on the source branch succeed whereas a base on the target branch fails. We perhaps just need to codify that "something special" -- some rule that says which base to consider the "better one" depending on the relative ages of ... A1, B1, A3, B3, and A2. + = The User's Perspective = + Let's remind ourselves broadly what we are aiming to achieve with this 'symmetric merge' development. An improved user experience for merging, of course. How are users going to appreciate this change as an improvement, exactly? To set the context, let's think back to the time when we introduced merge tracking. Forgive me for repeating what is old news to many of us. We could paraphrase that news as: + + * Subversion now remembers what revisions you have merged, so that if you want to merge "everything that's new since last time", you don't need to tell it. At least from a given source to a given target. + * When you want to merge back in the other direction, don't use a plain "merge" command because that will go through the motions of merging but produce the wrong result (in general). + * You can tell Subversion you are merging in the "other direction" by specifying this is a "reintegrate", and then it will do it right. + * If you specify "reintegrate", many more restrictions apply. + * Don't specify "reintegrate" when you are merging in the same direction as last time; if you do, Subversion will go through the motions but produce the wrong result. + * Don't expect to be able to merge between the same two branches again, after a reintegrate, without additional effort. + + As a user who understands Subversion's merging, we know which variant of the merge algorithm is needed for a given scenario and can tell Subversion whether it should do it the "reintegrate" way or the "non-reintegrate" way. But just as merge tracking is about Subversion knowing what revisions need to be merged so we don't have to tell it, it also has enough information to work out which variant is needed, so we shouldn't have to tell it. + + The essential points about 'symmetric' merge are: + + * We can now expect Subversion to perform a requested merge from A to B without having to tell it which variant of the merge algorithm is the right one for the job, since only one variant is right and it will figure out which one. + * We can now expect Subversion to perform a requested merge from A to B or B to A, no matter how many times we have merged from A to B and/or B to A before. + * In the current, crude implementation, all the "reintegrate" restrictions still apply when that style of merge is needed. (In theory, we could write a symmetric implementation.) + + I think one of the enablers for this advance is that we now have a better model of what merge tracking means [5]. This model allows us to describe what a merge will do in terms of bringing original changes (that is, non-merge commits) onto a branch, which is a bit higher level than describing merges in terms of mergeinfo and three-way diffs. In this model, "get me all the latest changes" has a consistent meaning no matter which way you last merged -- it is a symmetric model. + ---- = Appendices = == References == @@ -648, +668 @@ symmetric merge:: A ''complete merge'' that works in either direction between two branches, no matter which branch is regarded as the parent and which as the child, and no matter which direction any previous merges between those branches were performed. A ''complete merge'' is the normal kind of merge in systems such as ClearCase; this paper is about developing such a merge in Subversion. cherry-pick merge:: A merge that leaves a gap in the series of changes that have been merged from the source branch. This is obtained by specifying a minimum revision number. This is in contrast to a ''complete'' merge. It can be a ''forward'' or a ''reverse merge''. A ''cherry-pick'' merge does not necessarily ignore mergeinfo; in svn 1.7, the default behaviour of a ''forward'' cherry-pick merge is to use mergeinfo to omit any of the specified revisions that have already been merged. forward merge:: A merge that applies a pre-existing change again in the same sense. Symmetric merging is only concerned with ''forward merges''. Contrast with a ''reverse merge''.<<BR>> - reverse merge:: A merge that applies the inverse of a pre-existing change. Symmetric merging is not concerned with reverse merges. Merge tracking does not fully track reverse merges comprehensively; it only tracks whether a branch is currently considered to "have" a given change. The opposite of a ''forward merge''. Note that a single "svn merge" command can apply a mixture of ''forward'' and ''reverse merges''.<<BR>> - natural history:: The sequence of path-revision coordinates where a node existed, if you trace it back through history along its normal changes and any copy-from links. Nothing to do with merge arrows. == Drawing The Graphs ==
