tags vs branches in a repo

[Robert Collins]

On Thu, 2006-05-11 at 15:26 +1000, Martin Pool wrote:
> Please poke this straw man:
> 
> We now have repositories which can contain branches; branches are just
> directories containing a small number of control files.  It's cheap and
> (at least relatively) fast to pull or merge between two branches in a
> repository.  You can, with a plugin, list all the branches.
> 
> There are proposals for tags but they are either a bit limited
> (unversioned tags) or have not quite the right semantics (tags created
> by new versions) or introduce substantially more complexity (meta-branch 
> revisions).
> 
> 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.
> 
> [*] (Which suggests we should have a merge --overwrite too, which overwrites
> the tree with the merge source.)
> 
> I can think of some drawbacks, which I'll send in a separate post; I'll
> just float this for now.

Well, I think the following are the key downsides:
 * It makes tags 'cheap' or 'expensive' depending on how they are
managed. This is unintuitive.
 * It makes 'cheap' tags depend on knowing about and using repositories.
I think the *best* thing about our repositories is that no other feature
depends on them at the moment.
 * It collapses two quite different concepts 'line of development' and
'important revision' into one - which makes it harder to talk sensibly
about them, now that they are confounded.

Its important to note that in the Arch community, using a branch to
record tags was an optional approach. The tags for tla itself were
maintained as 'configs' - a record of many branches at a single point in
time - stored in a 'dists' branch which maintained many such meta-data
files. Our nested-tree proposal will do that in a much nicer, integrated
fashion, and is not incompatible with tags as branches or tags as tags.

+1 from me on having the tools to be able to choose to do tags as
branches.
-1 from me on documenting that as 'how to do tags' and/or making it our
best practice.

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: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060512/7e61f5cb/attachment.pgp