[RFC] Meta-branch

[John Arbash Meinel]

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.

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

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.

>  * 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.

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

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060221/f9a81e66/attachment.pgp