Best practices for tagging on branches

[Dirkjan Ochtman]

On 25/04/2009 01:35, L. David Baron wrote:
> The current procedure Mozilla uses for this is essentially:
>    hg branch release-branch-name
>    [ modify version number and commit change to branch ]
>    hg tag release-name
>    hg ci -m"Tagged release-name."
>
> Instead, it seems safer to avoid having multiple heads in the
> history of the .hgtags file, by committing tags only to heads that
> are intended to be merged, e.g:
>    hg branch release-branch-name
>    [ modify version number and commit change to branch ]
>    hg up -rdefault
>    hg tag -rrelease-branch-name release-name
>    hg ci -m"Tagged release-name."
>
> Does this practice seem worth documenting?  Does it have any
> disadvantages that I'm not aware of?

I've thought that it might be worthwhile to forbid tagging changesets 
that where ancestor(tagging, tagged) != tagged, i.e. the tagging 
changeset must be a child of the tagged changeset. Not doing so caused 
some problems for some guy a while back. Not sure that comes down to the 
same rules you're proposing, though.

Cheers,

Dirkjan