I have a script running some Mercurial commands in non-interactive mode on a build server. One of the commands merges two branches and there is always a conflict in the
Mercurial 3.1 (2014-08-01) introduced internal:tagmerge. It's marked as experimental so be careful. Here is preamble from changeset (you can find more details about algorithm if you follow the link):
Add a new internal:tagmerge merge tool which implements an automatic merge algorithm for mercurial's tag files
The tagmerge algorithm is able to resolve most merge conflicts that currently would trigger a .hgtags merge conflict. The only case that it does not (and cannot) handle is that in which two tags point to different revisions on each merge parent and their corresponding tag histories have the same rank (i.e. the same length). In all other cases the merge algorithm will choose the revision belonging to the parent with the highest ranked tag history. The merged tag history is the combination of both tag histories (special care is taken to try to combine common tag histories where possible).
The algorithm also handles cases in which tags have been manually removed from the .hgtags file and other similar corner cases.
In addition to actually merging the tags from two parents, taking into account the base, the algorithm also tries to minimize the difference between the merged tag file and the first parent's tag file (i.e. it tries to make the merged tag order as as similar as possible to the first parent's tag file order).
tagmerge works only with tag files, so to use it you should set merge-patterns. To do this on per command basis use --config option:
hg merge -r REV --config merge-patterns..hgtags=internal:tagmerge
Or to do this on per repository basis add to your repo config .hg/hgrc this:
[merge-patterns]
.hgtags=internal:tagmerge