Some things I'd like to point out:
1) Most-recent-ancestor is a special case of ancestry-set. When the
ancestry set of a revision includes all revisions on some
continuous path from the revision-tree root, the MRA algorithm can
be used. If there's a discontinuity, you need the general AS merge
2) Most-recent-ancestor covers what I think is the most common
repeat-merge situation: work has been done on a branch, but regular
main->branch merges have occurred, and now one wants to merge the
branch back to the mainline.
I suspect that the second most common repeat-merge situation does
require ancestry sets -- you've got a development and a release
branch, a few individual patches have been pushed from dev to rel,
and now you want to merge the entire dev branch to release.
3) It's possible to do most-recent-ancestor with CVS, through careful
use of labels: you tag the branchpoint, you tag the branch you're
merging from right before each merge, you tag the branch you're
merging to right after each merge, and you always give cvs update
two -j options. It's a pain but it works.
The GCC team has documented this procedure and uses it for all
branch development. I suspect we're going to see 1.0 Subversion as
a step backward in this regard if 'svn merge' can't do this at all,
even with the equivalent kludges (cp-ing every merge point into the
tags directory). I don't know if 'svn merge' has the equivalent of
cvs update -jTAG1 -jTAG2.
Given all these things, I think it's plausible to talk about doing MRA
real soon (1.1 at the latest, 1.0 would be nice) and AS later, as a
generalization. And even if nothing uses the information, I would
like to see 'merge arrows' (borrowing terminology from ClearCase) in
1.0, so that it's there for later versions to use. Going back and
adding them to a repository after the fact is usually infeasible.
I *think* it's plausible to do merge arrows, and in fact ancestor
sets, entirely with revision properties. For MRA functionality, all
you need is a 'svn:mergedfrom' prop on the merged revision that points
to the indirect ancestor. AS is a bit trickier; you put a list of
(merge start, merge end, add/subtract) tuples as properties on the
merged revision, and walk up the revision graph building the set.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun Dec 22 07:43:52 2002