[RFC] largefiles - "system-wide" cache

[Na'Tosha Bard]

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.

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