tags vs branches in a repo

[Martin Pool]

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.

-- 
Martin