Change order of lines in .hgtags to alleviate merge conflicts?

[Laurens Holst]

Op 3-4-2011 4:47, Laurens Holst schreef:
> Op 3-4-2011 1:37, Jason Harris schreef:
>> On Apr 2, 2011, at 11:02 PM, Greg Ward wrote:
>>> On 02 April 2011, Jason Harris said:
>>>> What would people think about changing the 'hg tag<tagname>'
>>>> command so that it inserted the tags in the list of tags according to
>>>> the changeset hash or according to the tag name. The reason for doing
>>>> this is to improve merges when tags change on separate branches.
>>> You can't do that: order matters in .hgtags.  Think about what happens
>>> if you create tag foo, then in separate branches you move the tag and
>>> I delete it.  In the merge, one of us *has* to get a conflict and
>>> .hgtags has to record how it was resolved.  It does this by printing
>>> multiple entries for the tag, and sorting out exactly what it all
>>> means when reading .hgtags.
>>>
>>> Roughly speaking, order in .hgtags reflects the order in which tags
>>> were created/modified/removed.
> [...]
>> So... I don't understand why you say 'order matters'. In what way 
>> does it matter?  As long as there are no duplicates in the list of 
>> tags in .hgtags I can reorder the lines in the list and the tags will 
>> work exactly the same.
>
> It means that if I tag a changeset with an existing tag name, it 
> overwrites the old one but the old one still appears in .hgtags, 
> before the new one (twice, actually). To determine the hash for a tag 
> it picks the one that appears last in the list, thus it is an ordered 
> list and order matters.

Also I think this add-only approach was chosen to reduce the risk of 
repository corruption, e.g. in case of a power failure before the write 
cache is written to disk. Scrambling the order would break this property.

~Laurens

-- 
~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, developer, Utrecht, the Netherlands
Website: www.grauw.nl. Backbase employee; www.backbase.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6034 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110403/bab74190/attachment.bin>