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

Sun Apr 3 02:45:29 CDT 2011

On Sat, Apr 2, 2011 at 10:35 AM, Jason Harris <jason at jasonfharris.com> wrote:
> Hi All,
>
> 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.
>
>  For instance assume I have the following list of tags in .hgtags:
>
> 910ff8b067abb1b241210f0f68241af26a437e7e Stable
> 8c28ed106bed1dd225735724925e2e450351f2ba SelfHosting
> 87004d4188869d5e37d775f339a6f36ebf1b8896 SCEventsFineGrained
> 14cdcb25e5e8f28199772549d00754c298e162e7 SCEventsFineGrainedEnd
> c508151cd2d1ce02c7d8423f9cb3c0474c0ecad5 WritingXMLConnections
> 2fe32abf51d992641749f07b9645ba691a90a705 RollValidation
> 24d7db22fc86d1f09100bd82643af848bf918170 BF-UnfinishedRevision
> b7b7017cccffd9523d9ad1e358cdf809fecb1523 BF-HistoryNIBExperiment
> 283a7f10c338f05dc9226032ef6e18a91ef82133 RemoveLegendCode
> e01b089ae1954b188fa24383f98b8e505ec02f6d StableBeforeMarks
> 113337dee3c6a920e8e02f5d47c73f134e4a591b MoveMercurialTempFile
> 72bf6b03f21482be1f3711d2ee0b04996b73fa8e release0.9.0
> 7ed9b844dd67b45ec768599716f9f860320c78be release0.9.1
> 266d6d82366b0ada26c0d28c393e51e12bf0a47b release0.9.2
> 14c71c57ab6eba2c2bedeb06cf671b6d2d666757 release0.9.3
> 0bbec94296a77885b2007e78638c5296b8f0cc5d release0.9.4
> f27460ab1fadc9c0ecb09cce8869f9e1f430bd77 release0.9.5
> 6472733cf2e30d5e08376c6150124f8d93252fca release0.9.6
> c0e38918cdd30c5170e5a66c5e41e10f2afc4932 release0.9.7
> 53d449e329b2ae010e9afee079c911a3384e97db release0.9.8
> 1f7d725dd7e5c851a74a3d1942e53dddca67efc4 release0.9.9
> b2f37d1f0708fd753fbe13cc8a8b7b38ee05dfe1 release0.9.10
> 880f2ab960bc2d2f78033cf02ae661ece82223fd release0.9.11
> 417bc5416b38302acbaa29fc7aef4a9b66cdebea release0.9.12
> b4c0475ebda495e2bee5089aab04dcf714506751 release0.9.13
> d9af1d818c0c84fd69778a619217c1ba711d9892 release0.9.14
> d6a74287393420aba2cd688d8875b5c058698800 release0.9.15
> 119e3b0a8fc6a359d67e274301cf94e89029b682 release0.9.16
> 82f56d562b9646d3597dd5b967a459c36241867a release0.9.17
> fa4406a02941e866c9888c2dda9d4c1c63fb1269 release0.9.18
> 30e5bdf18890f52be8b554bf066060d9ee51a92b release0.9.19
> fa4406a02941e866c9888c2dda9d4c1c63fb1269 latestRelease
>
>
> Option 1:
>
> Instead what if I listed these lines according to their sha hash
>
> 0bbec94296a77885b2007e78638c5296b8f0cc5d release0.9.4
> 113337dee3c6a920e8e02f5d47c73f134e4a591b MoveMercurialTempFile
> 119e3b0a8fc6a359d67e274301cf94e89029b682 release0.9.16
> 14c71c57ab6eba2c2bedeb06cf671b6d2d666757 release0.9.3
> 14cdcb25e5e8f28199772549d00754c298e162e7 SCEventsFineGrainedEnd
> 1f7d725dd7e5c851a74a3d1942e53dddca67efc4 release0.9.9
> 24d7db22fc86d1f09100bd82643af848bf918170 BF-UnfinishedRevision
> 266d6d82366b0ada26c0d28c393e51e12bf0a47b release0.9.2
> 283a7f10c338f05dc9226032ef6e18a91ef82133 RemoveLegendCode
> 2fe32abf51d992641749f07b9645ba691a90a705 RollValidation
> 30e5bdf18890f52be8b554bf066060d9ee51a92b latestRelease
> 30e5bdf18890f52be8b554bf066060d9ee51a92b release0.9.19
> 417bc5416b38302acbaa29fc7aef4a9b66cdebea release0.9.12
> 53d449e329b2ae010e9afee079c911a3384e97db release0.9.8
> 6472733cf2e30d5e08376c6150124f8d93252fca release0.9.6
> 72bf6b03f21482be1f3711d2ee0b04996b73fa8e release0.9.0
> 7ed9b844dd67b45ec768599716f9f860320c78be release0.9.1
> 82f56d562b9646d3597dd5b967a459c36241867a release0.9.17
> 880f2ab960bc2d2f78033cf02ae661ece82223fd release0.9.11
> 87004d4188869d5e37d775f339a6f36ebf1b8896 SCEventsFineGrained
> 8c28ed106bed1dd225735724925e2e450351f2ba SelfHosting
> 910ff8b067abb1b241210f0f68241af26a437e7e Stable
> b2f37d1f0708fd753fbe13cc8a8b7b38ee05dfe1 release0.9.10
> b4c0475ebda495e2bee5089aab04dcf714506751 release0.9.13
> b7b7017cccffd9523d9ad1e358cdf809fecb1523 BF-HistoryNIBExperiment
> c0e38918cdd30c5170e5a66c5e41e10f2afc4932 release0.9.7
> c508151cd2d1ce02c7d8423f9cb3c0474c0ecad5 WritingXMLConnections
> d6a74287393420aba2cd688d8875b5c058698800 release0.9.15
> d9af1d818c0c84fd69778a619217c1ba711d9892 release0.9.14
> e01b089ae1954b188fa24383f98b8e505ec02f6d StableBeforeMarks
> f27460ab1fadc9c0ecb09cce8869f9e1f430bd77 release0.9.5
> fa4406a02941e866c9888c2dda9d4c1c63fb1269 release0.9.18
>
> ie ordered the 'lines' according to their sha hash's in the .hgtags file. The reason for making this change is say if I add a new tag or change a tag in my copy of the repository, and if *someone else* in their repository adds a different tag, then it's much less likely when a merge happens that there will be a merge conflict. As it currently stands now, booth my tag and the other persons tag would be added to the bottom of the .hgtags file so when the two versions are merged it's an automatic merge conflict.
>
> However, if the tags are ordered according to changeset hash than adding a tag is not as likely or is unlikely to cause merge conflicts, since my tag and his tag will likely be inserted in different places in the .hgtags file. (Ie since the sha's are randomly distributed then so too will my tag and his tag be randomly distributed in this file. Thus the probability that they overlap is much reduced.)
>
> Of course if the order of the tags lines in the .hgtags file is changed, then when mercurial adds a new tag / changes a tag, any previous tags of that name must be deleted from the .hgtags file.
>
>
>
> Option 2:
>
> What if we ordered the 'lines' according to the tag name:
>
> 24d7db22fc86d1f09100bd82643af848bf918170 BF-UnfinishedRevision
> b7b7017cccffd9523d9ad1e358cdf809fecb1523 BF-HistoryNIBExperiment
> 30e5bdf18890f52be8b554bf066060d9ee51a92b latestRelease
> 113337dee3c6a920e8e02f5d47c73f134e4a591b MoveMercurialTempFile
> 6939dcdd70bf127fdc79a9c72cc4a8cfea3ff6df release0.9.0
> 6939dcdd70bf127fdc79a9c72cc4a8cfea3ff6df release0.9.0
> 72bf6b03f21482be1f3711d2ee0b04996b73fa8e release0.9.0
> 7ed9b844dd67b45ec768599716f9f860320c78be release0.9.1
> 266d6d82366b0ada26c0d28c393e51e12bf0a47b release0.9.2
> 14c71c57ab6eba2c2bedeb06cf671b6d2d666757 release0.9.3
> 0bbec94296a77885b2007e78638c5296b8f0cc5d release0.9.4
> f27460ab1fadc9c0ecb09cce8869f9e1f430bd77 release0.9.5
> 6472733cf2e30d5e08376c6150124f8d93252fca release0.9.6
> c0e38918cdd30c5170e5a66c5e41e10f2afc4932 release0.9.7
> 53d449e329b2ae010e9afee079c911a3384e97db release0.9.8
> 1f7d725dd7e5c851a74a3d1942e53dddca67efc4 release0.9.9
> b2f37d1f0708fd753fbe13cc8a8b7b38ee05dfe1 release0.9.10
> 880f2ab960bc2d2f78033cf02ae661ece82223fd release0.9.11
> 417bc5416b38302acbaa29fc7aef4a9b66cdebea release0.9.12
> b4c0475ebda495e2bee5089aab04dcf714506751 release0.9.13
> d9af1d818c0c84fd69778a619217c1ba711d9892 release0.9.14
> d6a74287393420aba2cd688d8875b5c058698800 release0.9.15
> 119e3b0a8fc6a359d67e274301cf94e89029b682 release0.9.16
> d2a3fd15d48ea4870c1bc0b270ea80770239ba7a release0.9.17
> fa4406a02941e866c9888c2dda9d4c1c63fb1269 release0.9.18
> 30e5bdf18890f52be8b554bf066060d9ee51a92b release0.9.19
> 283a7f10c338f05dc9226032ef6e18a91ef82133 RemoveLegendCode
> 2fe32abf51d992641749f07b9645ba691a90a705 RollValidation
> 87004d4188869d5e37d775f339a6f36ebf1b8896 SCEventsFineGrained
> 14cdcb25e5e8f28199772549d00754c298e162e7 SCEventsFineGrainedEnd
> 8c28ed106bed1dd225735724925e2e450351f2ba SelfHosting
> 910ff8b067abb1b241210f0f68241af26a437e7e Stable
> e01b089ae1954b188fa24383f98b8e505ec02f6d StableBeforeMarks
> c508151cd2d1ce02c7d8423f9cb3c0474c0ecad5 WritingXMLConnections
>
> The same arguments as before apply for ordering via tag name, however the distribution of the tags is of course not going to be "as random" as the distribution of the sha hashes in Option 1. Still it would again alleviate conflicts on merge due to simultaneous tag additions / changes...
>
>
> What would others think of such a change? Would ordering on hashes be better or ordering on tag names? Either would likely alleviate some / many merge conflicts due to simultaneous tagging in different copies of the same repository...
>
> Cheers,
>   Jas
>
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>

It seems the tag order in the .hgtags file is relevant... I think the
last items on the file take precedence over the previous items, since
tags can be mentioned more than once on the .hgtags file. However I
don't really understand why this is so.

I would say that the .hgtags file has a lot of similarities to the
.hgsubstate file that mercurial handles automatically for the user:

- Both have lines that contain a "name" and a "tag".
- Both are not supposed to be directly modified by the user.
- Both contain repository meta-data.

So it is a bit weird that mercurial handles the merging of the
.hgsubsate file automatically, while it does not for the .hgtags.
It would seem that mercurial could handle the merging of .hgtags files
pretty much the way it merges the state of subrepos. The logic would
probably be very similar. Basically work on tags as sets, rather than
as a simple text file.

That said, I am not against your idea, but if something needs to be
changed, why not try to be ambitious and completely solve the problem?

Angel