[PATCH 3 of 3 V2] merge: add automatic tag merge algorithm

[Mads Kiilerich]

On 03/24/2014 07:31 PM, Angel Ezquerra wrote:
>
> > Your tool has the necessary information ... and I think it would be
> > reasonable to expect it to handle these common cases too.
>
> I thought about this a bit before going for a simpler algorithm as a 
> first step.
>

I think a simpler first step would be fine - as long as it not is 
enabled by default.

> It is true that the algorithm has the necessary information. However 
> it is not as simple as just choosing one tag or the other. We must 
> also combine the histories of the tags that are in conflict (or at 
> least preserve what the tags.findglobaltags algorithm calls the tag 
> "rank").
>
> For example, the local revision may have the following entries in it's 
> .hgtags file:
>
> HASH_A TAG_A
> HASH_B TAG_A
> HASH_C TAG_A
>
> While the remote .hgtags may be:
>
> HASH_A TAG_A
> HASH_D TAG_A
> HASH_E TAG_A
> HASH_F TAG_A
>
> In theory the merge algorithm should pick HASH_F as the hash of the 
> revision pointed to by TAG_A since it is the tag with the longest 
> history (i.e. the highest tag "rank"). However, what should the merged 
> tag history be? It seems that we could just keep the tag history of 
> the tag with the highest rank, i.e.:
>
> HASH_A TAG_A
> HASH_D TAG_A
> HASH_E TAG_A
> HASH_F TAG_A
>
> Would that be OK? It seems so, but we'd be "losing" the TAG_A history 
> from the local revision branch... It does not seem to really be a 
> problem and in fact there is no way around that I think. In fact this 
> is a problem that users face today when they must manually merge the 
> .hgtags file.
>

Yes, that is an important point. I have argued that we should be aware 
of these ranks and preserve them ... but I think the correct way to 
actually merge the tags primarily should consider the two parents + 
ancestor. Once the merge result had been decided it should try to 
preserve/create a "correct" rank for it.

"Rank" might by definition be good enough for consistently and 
efficiently "resolving" conflicts when "merging" .hgtags on runtime ... 
but I am not sure it necessarily also is the right way to resolve "real" 
merges.

> >> I don't think forcing the
> >> user to manually write some complex command line incantation in a
> >> perfectly normal scenario is a good idea. hg is not git :->
> >
> > I agree, no common case should leave the user in that situation. 
> With the
> > prompts mentioned above it would be so uncommon that nothing in the 
> existing
> > tests or your new tests would trigger it (I assume).
>
> I think if we agreed on the correct behavior in cases such as the one 
> I described above it could definitely be possible to solve most 
> (perhaps even all) conflicts without user intervention.
>
> Mercurial already has a built-in algorithm to resolve tag conflicts, 
> which is implemented in the tags/findglobaltags() function which I 
> mentioned above. We could put a requirement on the tag merge algorithm 
> that the merged tag file should be such that the output of the 
> findglobaltags algorithm does not change... We could perhaps even use 
> that findglobaltags algorithm for doing the merge. If we did there 
> would never be merge conflicts (at least undecidable ones).
>

Perhaps - that would be clever if it worked. The algorithm is by 
definition right for runtime merging, but I doubt it will merge 
"correctly" for real merges. And I assume it will fail to remove removed 
tags? That could perhaps be retro fitted somehow.

> However perhaps that is a bit to ambitious as a first step? That is 
> the main reason I did not try to pursue this sort of solution in the 
> first place.
>
> Maybe Matt or others that were around when the current tag 
> infrastructure was put in place could give their two cents?
>

I don't know. But it sounds like this project will end up clarifying and 
extending on TagDesign. You could perhaps improve that page and start a 
TagMergeDesign page and summarize the thoughts you have done and the 
questions that has popped up.

/Mads