Avoiding conflicts in .hgtags

[Peter Arrenbrecht]

On Mon, Dec 8, 2008 at 4:15 PM, Greg Ward <gerg.ward+hg at gmail.com> wrote:
> 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?

I think Mercurial should have a specialized merger for such files.
There are others, like .hgsigs, and there will be more, like
.hgsubrepo, etc.
-parren