branch handling

[Dan Christensen]

Thomas Arendsen Hein <thomas at intevation.de> writes:

> Related topic is naming of heads (i.e. repo-local branches), which
> can be done in a similar way to the current tags implementation, but
> this branch tag always applied to the latest child of the
> branch-tagged changeset. I don't know yet what should happen when
> such a branch gets split.

What about the following approach:  Have something called a "moving
tag".  The user can tag a specific version with a moving tag.  Then,
anytime a node is added to the repository (commit, merge, pull, etc),
each of its parent nodes is searched for moving tags, and all the
moving tags are *moved* to the new node.  

The result is that when a branch gets split, the first ancestor is
the one that inherits the moving tag, and its future siblings don't.
In the rare case that this is wrong, the user just applies the
moving tag to the correct head, and hg automatically removes it
from wherever it was (maybe with a -f option, or a warning, to
catch accidental reuse of the same tag name).

The convention could be that such tags are named things like
main-head, stable-head, devel-head, etc, since they always
point to heads.  Or maybe main-tip, stable-tip, devel-tip, etc?
Hmm, maybe they should be called "head tags" or "tip tags"?

Dan