On Sun, 2002-12-22 at 01:43, Zack Weinberg wrote:
> 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.
You can do it with the equivalent kludges. svn merge only knows how to
do the equivalent of "-j TAG1 -j TAG2", as it turns out. (In CVS, if
you only specify one "-j REV" option, CVS will apply pred(REV):REV to
the working copy, if I understand correctly. We don't have that.)
> 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.
I hope doing MRA sooner doesn't make it harder to do AS later, if that's
the eventual plan.
(Terminology note: I'm going to start calling it MRCA, for "Most Recent
Common Ancestor", instead of MRA, starting with the file I'm committing
to "notes". Sorry for the confusion, but I think it's clearer in the
long run.)
> 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.
You're only considering the simple merge-and-commit cases.
svn co URL1 wc
(cd wc/subdir1 && svn merge URL2 URL3)
(cd wc/subdir1 && svn merge URL4 URL5)
(cd wc/subdir2 && svn merge URL6 URL7)
svn ci
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 22 08:03:24 2002