[RFC] largefiles - "system-wide" cache

Na'Tosha Bard natosha at unity3d.com
Thu Oct 20 04:34:20 CDT 2011

2011/10/19 Benjamin Pollack <benjamin at bitquabit.com>

> On Oct 19, 2011, at 5:26 PM, Matt Mackall wrote:
> > On Wed, 2011-10-19 at 17:56 +0200, Na'Tosha Bard wrote:
> >> 2011/10/19 Carter, Eli <Eli.Carter at tektronix.com>
> >>
> >>> 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 agree.  This is also actually how kbfiles originally operated; it appears
> the logic got reversed or dropped in the move to largefiles.

Kbfiles is also very problematic when cloning locally between two machines
(and not involving the "centeral" server).  It only really works if you have
the same username/password on both machines.  So this is something to make
sure works in your fix.

> I'll submit two patches, if no one else is already working on it: one to
> add "hg clone --all-largefiles", and one to set things back to having a user
> *cache* and a canonical in-repository *store*.

Great -- I strongly doubt I would have time to get to this before Nov 1st.


*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/20111020/3cfbb4a6/attachment.html>

More information about the Mercurial-devel mailing list