[RFC] Meta-branch

[Robert Collins]

On Tue, 2006-02-21 at 21:32 -0600, John Arbash Meinel wrote:
> Robert Collins wrote:
> > The discussion about tags and earlier about the location of subtree-root
> > branch storage/branches seems to coalesce into a single prerequisite
> > feature: a branch of data about the users branch. This data should
> > propogate, and people should be able to record decisions in it without
> > 'committing' to their source code.
> > 
> > So heres a proposal for a meta-branch feature.
> > 
> > A meta branch records data about a branch. It coexists with the branch
> > at the same URL and has:
> >  * Its own 'meta-last-revision'
> >  * One weave/knit for each thing it records, today that will be 'tags'
> > and 'subtree-locations' and stored in the repository
> > as .bzr/repository/tags and .bzr/repository/subtree-locations
> 
> My concern is that 'tags' should actually be a branch property, not a
> repository property.

Its a branch property delta compressed by the repository.

> Otherwise, how do I give "release-0.7" to both libfoo and progbaz.

Indeed, that was a problem with the initial proposals.

> If we make them a repository property, I always have to fully qualify my
> tag names "libfoo-release-0.7"
> 
> It is workable, but since I have to have the environment of a branch in
> order to 'get', it seems unnecessary.

you would not need to in this proposal: the meta-last-revision marker
gives you a unique, branch qualified, copy of the tags - you will not
see other branches tags.

> >  * Conflicts in meta-branch pull operations are recorded
> > in .bzr/checkout/somefilename.
> >  * Operations on these files - i.e. bzr vitags - will validate the file
> > and commit them immediately to the meta-branch.
> >  * conflict resolution on them will only do a commit to the meta-branch
> > when all the meta-data is resolved.
> >  * if possible all the files in the metabranch will be merged in the
> > same way, but that is not a requirement.
> > 
> > 
> > This should allow simple implementations of tags and subtree locations,
> > with minimal performance impact and the ability to share tags and update
> > the locations of subtrees for old branches without 'dummy' commits.
> > 
> > Rob
> 
> I like the simplicity of the design. Having meta-information about the
> branch, versioned as meta-information (as a layer above the branch, not
> below it), seems correct.
> 
> I wonder, though about merging. For example, subtree locations seems to
> just be a stack. Where all locations are reasonable, just that they
> should take LIFO precedence, and sometimes when one is not available,
> you *will* try an earlier one. Versus 'tags' which seem like only the
> latest one should be readily available. The old ones are only present
> for posterity and merging sake.

Its entirely possible that we want different merge tweaks on the two
files in the meta-branch, but as they are both versioned I don't see it
being really relevant to the meta-branch proposal per se.

> So, I'm not 100%, but I wouldn't give you a minus on it.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060222/26fd9cd5/attachment.pgp