[PATCH RESEND] largefiles: speed up the check if largefiles should be added to repo requirements

Na'Tosha Bard natosha at unity3d.com
Fri Oct 28 10:23:03 CDT 2011


2011/10/28 Dominik Psenner <dpsenner at gmail.com>

> >this also signifies that we need largefiles
>
> Actually: no. You don't require the largefiles extension until you actually
> have .hglf in the store.
>
> > and is faster than walking the store -- epsecially if the repo is large.
>
> Yes, it would be. But again, it would add the largefiles requirement even
> if
> it is not required yet. I.e.:
>
> $ touch .hglf
> $ hg st
> $ hg revert
> $ cat .hg/requirements
> largefiles
> **OPS**
>
> >It won't help much in the I-have-largefiles-enabled-but-don't-use-
> >them case
>
> Instead it does. It checks the first level of files and folders in the
> store
> (which is normally a quite small number of files and folders) and adds the
> requirement once it finds .hglf there. We could discuss if we should not
> walk the files and blindly guess the location of .hglf in the store, but as
> said I was afraid from going that far. :-)
>
> > but it will help in the "I-do-have-largefiles-enabled-and-I-do-
> >use-them" case.
>
> In this case largefiles are already in the requirements and we don't have
> to
> add the requirement anymore.
>

I have a few comments here, but I'm content to let this go until I actually
do some more profiling with largefiles.  It's possible Largefiles behaves
differently than Kbfiles in this regard, so I'd better do some more research
before arguing my point more (or otherwise risk putting my own foot in my
mouth).

But in any case, I do think your patch should go in (even if I think it can
be extended a bit, and probably make some other use cases faster).

Cheers,
Na'Tosha


-- 
*Na'Tosha Bard*
Build & Infrastructure Developer | Unity Technologies

*E-Mail:* natosha at unity3d.com
*Skype:* natosha.bard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111028/e20e688c/attachment.html>


More information about the Mercurial-devel mailing list