Avoiding conflicts in .hgtags

[Greg Ward]

I recently got burned by conflicts in .hgtags.  (It's not that I'm too
stupid or lazy to resolve the conflict, but I'm trying to convert a
git repository semi-manually by replaying the patches and recreating
tags and branches.  I want this conversion to run without manual
intervention once I have finished the shell script that does it.)

That made me think, "Gee, it should be really easy to trigger a
conflict in .hgtags".  I just tried it out and it is:

  * create your wonderful new piece of software
  * "hg tag 1.0"
  * "hg branch 1.0-branch"
  * commit a fix on 1.0-branch
  * "hg tag 1.0.1"
  * back on default, "hg tag start-next-feature" (or whatever)
  * then "hg merge 1.0-branch"

Oops!  That gets a trivial one-line conflict in .hgtags between
"start-next-feature" and "1.0.1".

Is anyone else bothered by this?  I mean, it's great that I can look
back in the history and see when tags were created.  But it does seem
weird that the mapping from tag name to commit ID can vary from branch
to branch.

Perhaps there is a "best practice" guideline waiting to be formulated
that goes something like this: 

  You can tag any changeset you like, but you should only create tags
  (i.e. modify .hgtags) on the trunk.

Or maybe it should be:

  You can tag any changeset you like, but you should only create tags
  (i.e. modify .hgtags) on the trunk and then merge that modification
  to all active branches.

Thoughts?

       Greg