Re: disrstate._check(link|exec) modifies repo dir mtime
On Sun, 16 Oct 2016 14:08:52 +0200, Mads Kiilerich wrote: > On 10/16/2016 12:29 PM, Yuya Nishihara wrote: > > On Sat, 1 Oct 2016 11:35:40 -0700, Dorian Taylor wrote: > >> is there a reason why all this testing can’t go on in $REPO/.hg? > > No idea why, but there was an attempt to move check* files to .hg/cache. > > > > https://www.mercurial-scm.org/pipermail/mercurial-devel/2015-October/074885.html > > https://www.mercurial-scm.org/pipermail/mercurial-devel/2015-November/074971.html > > About that: > > I don't think this is sufficient. This case can occur, for instance, if > > someone naively copies a repo from one machine to another with a USB > > stick. Or perhaps they've done a naive recursive chmod. Then we're > > permanently stuck thinking our filesystem doesn't have exec bits. If > > our fast-path files don't have the right permissions (for who knows > > what reasons), then we have to do the entire slow path. > > I don't see how copying or chmod can trigger wrong measurement of file > system capabilities. "Wrong" files will be removed again - just like in > the old slow path. The slow path will pretty much be the existing slow > path - it will not be slower than before but it will usually not be used. Can we distinguish "no exec bit support" with "cache/checkisexec was chmod by user" ? If a repository is copied through VFAT USB stick, exec bit could be dropped from both checkisexec and checknoexec. ___ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial
Re: disrstate._check(link|exec) modifies repo dir mtime
On 10/16/2016 12:29 PM, Yuya Nishihara wrote: On Sat, 1 Oct 2016 11:35:40 -0700, Dorian Taylor wrote: is there a reason why all this testing can’t go on in $REPO/.hg? No idea why, but there was an attempt to move check* files to .hg/cache. https://www.mercurial-scm.org/pipermail/mercurial-devel/2015-October/074885.html https://www.mercurial-scm.org/pipermail/mercurial-devel/2015-November/074971.html About that: I don't think this is sufficient. This case can occur, for instance, if someone naively copies a repo from one machine to another with a USB stick. Or perhaps they've done a naive recursive chmod. Then we're permanently stuck thinking our filesystem doesn't have exec bits. If our fast-path files don't have the right permissions (for who knows what reasons), then we have to do the entire slow path. I don't see how copying or chmod can trigger wrong measurement of file system capabilities. "Wrong" files will be removed again - just like in the old slow path. The slow path will pretty much be the existing slow path - it will not be slower than before but it will usually not be used. Also, putting knowledge of the existence of .hg/cache here is a classic layering violation. Yes, it is a layering violation - a convenient one. I don't know if it deserves honorary mentioning as being classic. It just uses .hg/cache if it is available. Using .hg for probing properties outside .hg will inherently be some kind of violation. The whole file system capabilities checking (including casing) should arguably move into the vfs layer as cached instance properties and support for these "capabilities" should not be tied to the platform but to the file system. The implementation proposed in these patches is however more complex than the old one and there might be bugs and design flaws ... /Mads ___ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial
Re: disrstate._check(link|exec) modifies repo dir mtime
On Sat, 1 Oct 2016 11:35:40 -0700, Dorian Taylor wrote: > is there a reason why all this testing can’t go on in $REPO/.hg? No idea why, but there was an attempt to move check* files to .hg/cache. https://www.mercurial-scm.org/pipermail/mercurial-devel/2015-October/074885.html https://www.mercurial-scm.org/pipermail/mercurial-devel/2015-November/074971.html Per mpm's comment, we can move check* files out of the repo root. ___ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial
