[RFC] largefiles - "system-wide" cache

Greg Ward greg-hg at gerg.ca
Tue Oct 18 19:49:43 CDT 2011


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).

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.

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.

Greg


More information about the Mercurial-devel mailing list