tags vs branches in a repo

[Jan Hudec]

On Fri, May 12, 2006 at 09:48:30 -0700, John A Meinel wrote:
> Jan Hudec wrote:
> 
> ...
> 
> > 
> > This leads me to think, that tags are really just a kind of revision
> > properties. I think of revision properties that would have a type and
> > set of values, could be added and removed to/from existing revisions and
> > would allow searching a revision by them.
> > 
> > One type would be 'tag', that would have special property that only one
> > revision on a branch can have a particular value. Another type could be
> > 'annotation', that could contain arbitrary strings. Signatures, both
> > author's and other (like reviewer's etc.) could be implemented with that
> > as well.
> > 
> > Similarly to file properties I'd say that each property type would need
> > a class implementing it. The property would be copied around without
> > that, but could only be manipulated via that class.
> > 
> 
> I'm curious how this could be done. It would need to be some sort of
> 'post-commit' properties that can be added/removed without actually
> effecting the revision itself. (Since it would be separately signed).
> 
> I know monotone has all properties done separately using 'certificates'.
> But I don't know how they inform people that a certificate has been
> added or revoked.
> 
> At one point I could see doing it with the same mechanism I was
> discussing for with Tags. Where you have a new random meta-revision-id,
> which is used to indicate hierarchy (precedence).

Yes, that way. Special knits with their own revisions. I am not sure how to
split the properties into various knits, but basically that's the method.

The revisions of this knit may need signatures as well. In fact we may need
somethng similar to monotone certificates.

> But you still have all the issues of finding and resolving conflicts.

Well, set properties can't really conflict. So only conflicts are on those
properties that are somehow constrained -- which tags are. When you pull from
a repo that contains the same tag pointing to different revision, you would
have to decide which one to keep.

> I also like having important stuff be part of the revision itself, but
> that depends on how important it is, and you have to know it at commit time.

Sure. There is immutable stuff that is part of revision itself. But then
there can be additional stuff that needs to be separate.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060513/3ac628b6/attachment.pgp