Zack Weinberg wrote:
> 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
> algorithm.
>
> 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.
Basically yes. Without ancestry sets you get potential false conflicts
in the merge, due specifically to the patches which have been pushed to
rel. A good 3-way merge actually eliminates many of these false
conflicts, but ancestry sets eliminate them all.
> 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.
*Right*.
> 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
This is what I felt we could get into 1.0 without too much work. If the
merge tracking information is being put in by 'merge', we can at any
rate handle repeated merging (by hand) a lot better than CVS.
> 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.
>
> zw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 23 09:22:07 2002