largefiles: still confused about store vs cache on the client

Dominik Psenner dpsenner at gmail.com
Tue Oct 25 01:41:40 CDT 2011


>Yup, that makes a lot of sense for a hosting service. (Aside: do you
>also save the 1,999 x 650 MB of bandwidth from all those redundant
>uploads?)

That would be awsome, but requires some pre-upload checks.

>*But* the downside here is that by sticking largefiles from unrelated
>repos into one big cache, it's hard to purge the largefiles for a repo
>you no longer care about. It would be nice if we had the option of
>splitting up the largefile cache by repo -- and I don't mean "clone as
>branch" repo, I mean distinct projects with unrelated repos.

Then bfiles are no longer shared across repositories and the exactly same
file that is reused among lots of repositories uses memory where it doesn't
have to. *eek*

This logic should IMHO built into the application logic as a "purge" that
checks how often a file is hard linked and only purges it for real if it is
hard linked less than 2 times.

JMTC, cheers!



More information about the Mercurial-devel mailing list