LargefileExtension recommendations

[Na'Tosha Bard]

2012/1/31 Roger Kratz <Roger.Kratz at teleopti.com>

> Hi****
>
> ** **
>
> We’re about to move to Hg from a centralized vcs. One thing I’ve been
> trying to get a deeper understanding of is the largefileextension. Google
> has thought me the basics, but some questions are still there that
> hopefully you guys can help me with…****
>
> ** **
>
> **·         **The “problem” with Hg + large binary files - is it mainly
> caused by the file’s size or the fact that the file is binary? Or is it the
> combination? From what I’ve understand it’s because a file is binary and
> therefore the “delta” cannot be created efficiently if the file is
> modified/replaced. If so, why this stuff about 10 mb limitation? Wouldn’t
> it be better to skip the size part and just use *.dll (I’m on Windows) as
> pattern? Why is it bad to put a small, say 2kb binary file, to the
> largefile store?
>
It's both.  Your explanation is correct; the binary files usually can't be
compressed (at least not much), and we can't create deltas in the same way
as with regular files.  The "end user" problem is a really huge clone.
Often times it's a really huge clone full of files that don't update often,
or you aren't interested in having the whole history of, anyway.

You can, instead of using 10 mb limitation only, set up largefiles to match
patterns so, for example, all .dll files, are added as largefiles, if you
choose to.

> ****
>
> **·         **AFAIK it’s the client (we’ll have a central repo) who
> decides what’ll be put in the largefile store? Is this mandatory or is it
> possible to decide this server side? Or at least prevent a gigantic binary
> file be pushed to the server repo? Using a hook maybe?
>
No, it's always the client that decides what gets added as a largefile.  I
don't know of any way to control this server-side.  But once your repo
requires largefiles, all clients will need largefiles turned on in order to
interact with the repository, and by default, all files >= 10.0 MB will be
added as largefiles (you can lower this on the client side, if you wish).

> ****
>
> **·         **There seems to be quite many issues reported with
> largefileextension currently – is it considered to be “safe” using it in a
> live env yet? A safe (?) alternative would be to wait, because it seems
> “lfconvert” can be used when/if we want to use it, removing the history of
> the largefile in the repo?
>
You can convert an existing Mercurial repository to a largefiles repository
using lfconvert at any time.  Regarding whether it is safe; that is hard to
say.  We have been using largefiles since long before it was largefiles in
production.  We have run into problems along the way, but I have spent a
lot of time fixing bugs and sending patches back to the Mercurial project.
2.1 will be the most stable and most optimized largefiles release, by far.
My gut feeling is to say it has some "rough edges", but it is certainly
usable if you have a real problem you need to solve.  However, if your
binaries are not very big and don't change often, you might not actually
see much difference in clone sizes using largefiles vs. vanilla Mercurial.

Na'Tosha

> ****
>
> ** **
>
> Thanks****
>
> Roger****
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
>


-- 
*Na'Tosha Bard*
Build & Infrastructure Developer | Unity Technologies - Copenhagen

*E-Mail:* natosha at unity3d.com
*Skype:* natosha.bard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20120131/67935f74/attachment-0002.html>