tags vs branches in a repo

[Jan Hudec]

On Thu, May 11, 2006 at 15:26:50 +1000, Martin Pool wrote:
> How about instead doing something similar to arch and svn by just making
> a practice of using branches within a repository as tags.  To create or
> update a tag you can pull, pull --overwrite, or merge onto it[*].  This
> makes tags versioned, but without introducing a new time dimension.  And
> we don't have to do a new feature, we can just improve the one we
> already have.

I just realized one more good argument against it.

It is often useful to ask which tags point to a particular revision or
to it's ancestor. Then you can use tags to mark various features and
have an easy weay to see which of them were merged in some branch.

It is a problem to ask which branches have some revision as current,
mainly because there is no list of branches. But with tags in a
versionedfile there would be a list of them, soasking which tags point
to some revision would be easy.

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.

-- 
						 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/20060512/08d8a63c/attachment.pgp