tags vs branches in a repo

[Michael Ellerman]

On 5/11/06, Martin Pool <mbp at canonical.com> 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.

I like it a lot, I'm just not sure how it would work in practice, ie.
the UI. Any ideas?

If we can make it still "bzr tag foo", "bzr diff -r tag:foo" etc. then
I'm all for it.

If it's a case of "bzr doesn't have tags but you can do something
similar by .." then I think that would be a misfeature.

It'd also have to work for non-repo branches, and transparently to the
user. But that might be doable by just quietly turning their
standalone branch into a repo?

BTW, I never got 'round to posting the updated version of my tags
plugin. It doesn't solve the problem properly, but does work. ie. it
stores tags in .bzrtags, so they're pullable/mergeable, but manually
so. Might keep some people happy.

cheers