[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Repeated merge strategies

From: Zack Weinberg <zack_at_codesourcery.com>
Date: 2002-12-22 07:43:08 CET

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.

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.

zw

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 22 07:43:52 2002

This is an archived mail posted to the Subversion Dev mailing list.