Best practices for tagging on branches

[Greg Ward]

On Fri, Apr 24, 2009 at 7:35 PM, L. David Baron <dbaron at dbaron.org> wrote:
> In particular, it's possible to have two repositories that
> have the same set of changesets in which hg tags in the repository
> have different meanings.  This is the case because the meaning of hg
> tags is determined from the .hgtags file on *all* heads of the
> repository and the order of those heads in the repository, and the
> order of heads between repositories can be different even if "hg
> outgoing" and "hg incoming" say those repositories are the same.
>
> It's not clear to me that hg could have avoided this issue easily.
> But it seems that it is possible to describe best practices that can
> prevent it from causing problems.
>
> The best practice that comes to mind is that tags should not be
> committed on branches that are not intended to be merged.

I've thought a little bit about the problem and have mulled over a
strict policy like, "Only create tags on default".  Then there's never
any possibility of conflicts.  But it could make creating tags
inconvenient, and it loses the usual property of Mercurial tags that
the tag-creating changeset is often right after the tagged changeset.

Your proposed policy sounds like a fairly sensible compromise to me.
But my experience with industrial-scale Mercurial is so far nil, so
right  now it's all thought experiments.

Greg