[PATCH] merge: add automatic tag merge algorithm

[Mads Kiilerich]

On 02/19/2014 12:28 AM, Angel Ezquerra wrote:
> # HG changeset patch
> # User Angel Ezquerra <angel.ezquerra at gmail.com>
> # Date 1392597815 -3600
> #      Mon Feb 17 01:43:35 2014 +0100
> # Node ID f3eb8304d9bb59e78b50b42a9341a2063e1cb451
> # Parent  7648e9aef6eeab00a0946e877690e94fb12d389b
> merge: add automatic tag merge algorithm
>
> Try to automatically merge conflicting .hgtags files using the following
> algorithm:
> - keep all the tags that are on only one of the merge parents
> - out of the common tags:
>      - keep those that are exactly the same (including history) in both parents
>      - keep those whose "full tag history" (i.e. current node plus tag history)
>      is a super-set of the other merge parent "full tag history"
> - If there are no tags left the merge was successful.
> - If there are any tags left there was a conflict and the automated merge failed
>      - When this happens, fall back to a regular file merge, which in most cases
>      should open a merge tool (at which point the user can manually resolve the
>      conflicts).
>
> # Notes:
> - The algorithm assumes that tags are never removed from the .hgtags file. This
> should be true in most cases (particularly if the user does not normally modify
> the .hgtags file on its own). We could improve this merge algorithm to handle
> that case as well.
> - When the automated merge algorithm is successful, the merged tags are written
> in alphabetical order. There main reason is that tags._readtags returns a
> regular unordered python dict. We could change it to a sorteddict instead.
> If we keep it this way we should probably change the hg tag command so that it
> sorts tags when it modifies the .hgtags file as well.
> - All tests pass without modification. The added test passes as well (while it
> would fail without this change)

I think there are some essential disadvantages with this approach:
* It will completely rewrite the .hgtags, giving a messy history and 
making it almost impossible to merge manually with old un-sorted .hgtags.
* Manual fixing of .hgtags will no longer be possible ... and it will 
regress in handling of cases where it has been done.

I think it would be better if the algorithm started out by checking that 
both parents starts out as the ancestor and only have been appended to. 
If that is the case your new checks don't show any conflicts, it should 
take the new changes from one side and apply that on top of the other. 
That would be less intrusive and mostly address my concerns.

I have clarified http://mercurial.selenic.com/wiki/TagDesign a bit - it 
should be updated if a patch like this is accepted.

The tests should make sure to cover tricky cases like divergent change 
and removal of tags and that it is handled 'safely'.

/Mads