[RFC] largefiles - "system-wide" cache

Matt Mackall mpm at selenic.com
Wed Oct 19 16:26:13 CDT 2011


On Wed, 2011-10-19 at 17:56 +0200, Na'Tosha Bard wrote:
> 2011/10/19 Carter, Eli <Eli.Carter at tektronix.com>
> 
> >
> > > Seems reasonable. Actually I'd like someone to explain to me why we need
> > > two complete copies of all the largefiles on the local system.
> > > ;-) If that is in fact the case... so far I've mainly been reading the
> > code rather
> > > than actually *using* largefiles.
> >
> >
> > The purpose is so that when you do another clone of the repo from the
> > server that you don't have to download those 1.5GB files all over again.
> >  And the intent, from what I understand, was for these to be hardlinked so
> > you don't have multiple copies of it, just multiple references.
> > I don't know how well that works on Windows machines.
> >
> 
> I haven't looked into it in great detail, but I think it works fine on
> windows machines with Kbfiles (which work fundamentally the same way).
> 
> 
> > As (I think) it should be implemented:
> > ~/.largefiles (or ~/.hg-largefiles) should be a cache and only a cache.
> > $repo/.hg/largefiles should be a store.
> > I think we really need some way to say 'this repo must maintain a complete
> > store' so there is a way to assert that 'this repo is always complete'.  As
> > it stands, I worry about data getting lost in a convoluted
> > backup-and-restore shuffle.
> >
> 
> I think your proposal here is a good idea.  It is substantially more
> consistent, and it should fix our issue with cloning largefiles repos
> between multiple local repos on different machines.  And I also agree that
> we need a --backfill-largefiles option or --all-largefiles or something for
> clone, both for backup purposes, and also for the "fork" feature of some
> software tools.
> 
> Patches to fix both of these things would be welcome (at least by me).

I'd like to see this resolved before the first release if possible.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list