Avoiding conflicts in .hgtags

[Greg Ward]

On 12 December 2008, Matt Mackall said:
> All three can be merged just fine by normal textual merge tools. 
> 
> You could write an automated tool that would handle some of the bogus
> conflicts in hgtags, but you'd still have to deal with real conflicts
> (two people adding the same tag pointing to different things).
> 
> But if you regularly have to merge tags files, you probably have a
> process problem.

I disagree.  What about this process:

  * develop on trunk
  * tag "1.0"
  * branch "1.0-maint"
  * on the branch: fix bugs
  * on the branch: tag "1.0.1"
  * return to trunk, develop some more
  * tag "1.1"
  * merge "1.0-maint"

First, that is (IMHO) a perfectly valid reason to merge .hgtags.  The
only way to avoid it is to always create/remove/modify tags on the
trunk, which seems rather awkward.

Second, that example creates a bogus conflict in .hgtags between tag
1.1 and 1.0.1.  My hgmergetags script handles that case just fine,
since it's a "content-aware" merge rather than a generic textual
merge.  Would be nice if Mercurial supported something like that out
of the box, but I can't swear that my script is the most elegant
solution.

        Greg