[RFC] largefiles - "system-wide" cache

Justin Holewinski justin.holewinski at gmail.com
Wed Oct 19 06:04:54 CDT 2011

On Wed, Oct 19, 2011 at 5:22 AM, Na'Tosha Bard <natosha at unity3d.com> wrote:

> 2011/10/19 Greg Ward <greg-hg at gerg.ca>
>> On Tue, Oct 18, 2011 at 4:38 PM, Carter, Eli <Eli.Carter at tektronix.com>
>> wrote:
>> > The largefiles extension talks a lot about a system-wide cache.  There
>> are two problems with this.  First, this cache is per-user, not a
>> system-wide.  And secondly, it is more accurately described as a 'store'
>> than as a 'cache'.
>> I have been thinking about sending in a patch to rename it to "user
>> cache", but I had not realized that it's really a store. Thanks for
>> clarifying!
>> (In fact, I was going to propose moving it to ~/.cache/hg-largefiles,
>> since after all "it's a cache, it should go in ~/.cache to clarify
>> that it's safe to dispose of". Oops! Good thing I didn't get around to
>> that.)
>> > Regarding 'system-wide' vs 'per-user':
>> > The extension assumes files are in the system cache, but if one user is
>> cloning a repository from another user on the same machine, those files
>> _won't_ be in the "system-wide" cache, and the clone winds up without the
>> largefiles (and spews "Can't get file locally" errors).
> Yes, I've seen that several times.  We need to fix it correctly . . .
> somehow.  It only seems to work if you happen to have the same username and
> password on both machines :-)
>  Ick. Sounds like we need more test cases.
>> > Therefore, there are two things I'd like to see:
>> >
>> > 1: I'd like to have the extension populate $repo/.hg/largefiles in
>> addition to ~/.largefiles (using hardlinks where possible), and reference it
>> when looking for files.
>> 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.
> One use case: If you do branch-by-cloning server-side for example, your
> local clones can pull the largefiles they need out of the local cache rather
> than re-download them.
>> Tweak: it should be ~/.hg-largefiles, not ~/.largefiles.
>> > 2: I'd like to have an --all-largefiles option for hg clone and hg pull
>> that downloads all versions of all largefiles referenced by any changeset
>> included in the transfer.
>> Also seems reasonable, but it's unclear to me whether those downloaded
>> revs belong in ~/.hg-largefiles or $repo/.hg/largefiles. The
>> relationship between those two directories is still unclear to me.
Whatever the outcome of this discussion, I feel that having a config option
to set where the global cache/store is kept is mandatory.  If I want to
sandbox all of my Mercurial repositories to, say, /var/hg on its own
partition, then I do not want a large amount of repository data to be stored
in whatever home directory is associated with the Mercurial server user.
 Imagine the Mercurial server running as the www user.

>> Greg
> Cheers,
> Na'Tosha
> --
> *Na'Tosha Bard*
> Build & Infrastructure Developer | Unity Technologies
> *E-Mail:* natosha at unity3d.com
> *Skype:* natosha.bard
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel



Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111019/6449f1c5/attachment.html>

More information about the Mercurial-devel mailing list