[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: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2002-12-22 07:57:54 CET

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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.