> From: Greg Hudson [mailto:ghudson@MIT.EDU]
> On Sun, 2002-12-22 at 01:43, Zack Weinberg wrote:
> > 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.)
Doing MRCA sooner only prevents us from auto-detecting removals from an
AS. We can easily build AS adds for each node revision given MRCA
information.
Even given AS information actually supporting AS driven
semi-automated-merging (as opposed to AS driven queries) is a
challenging problem on it's own. (as the old design doc notes)
Folks who worry about branch merging will still find AS driven query
mechanisms a useful feature for branch maintanance sanity even if we
don't easily support doing semi-automated AS driven merges.
I think there's still a question in my mind if semi-automated AS driven
merges are worth doing. They seem fraught with silent conflict
potential. Esp. given the fact that we don't version sub-file chunks of
text specific to a programming language. (i.e. something like Stellation
or Intentional Programming where the versioned unit is smaller than one
file)
>
> > 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
>
Yeah, Zack's "svn:mergedfrom" property clearly needs to be able to store
multiple merge sources.
Bill
---------------------------------------------------------------------
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:26:42 2002