largefiles: overheads to hg startup

Matt Mackall mpm at selenic.com
Thu Oct 27 21:22:50 CDT 2011


On Tue, 2011-10-25 at 19:06 -0500, Andrew Pritchard wrote:
> That code path was added exclusively to add the 'largefiles'
> requirement to old-kbfiles repositories that didn't have anything
> largefiles-related in the requires file.  Since, again, Fog Creek has
> been shipping recent versions of largefiles with Kiln's auto-updating
> extensions, this code shouldn't really be necessary anymore: most, if
> not all, old-kbfiles repositories should now mention 'largefiles' in
> the requires file, and the worst case if they don't is that clients
> that don't have largefiles enabled will be able to mess with the
> repository, until some other action adds the requirement.  The call to
> checkrequireslfiles() in reposetup is a relic of the migration from
> the ignore-the-fact-that-unaware-clients-can-break-things strategy to
> the lock-them-out strategy.
> 
> Also, while we're looking at the code that adds the largefiles
> requirement, it would be faster to check only the current changeset in
> the commit hook (I thought I had already done that, but the code says
> otherwise).  It might also be appropriate to drop the changegroup hook
> and add the largefiles requirement in the putlfile wireproto command
> instead, since clients will always push largefiles with commits that
> add them; and handle pulls and unbundles by looking through each
> commit's manifest in wrapped pull and unbundle functions (or in a new
> changegroup hook; either way).  The code in manifest._search is very
> close to suitable for this, but not quite, since it looks for exact
> matches on entire lines rather than prefix matches.  Thoughts?

Whatever simple steps we can take before Tuesday to speed up the "I
foolishly enabled largefiles and I'm not using it" case would be good.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list