2GB limit

[Martin Geisler]

Maritza Mendez <martitzam at gmail.com> writes:

> 2. Does anyone know if any other dvcs system has solved the VM
> problem? If so we might put our "big file" projects in git or
> Mercurial until bzr can handle them.

Mercurial is also not designed for working with very large files since
it loads them into memory when merging and when computing diffs. People
in #mercurial tell me that Git has the same limitation.

However, we have several extensions that people use to tackle this
problem. The extensions all use the same basic idea: let Mercurial track
a small file that has a reference to the big file.

When you checkout a particular revision with 'hg update', the extension
will notice that you checkout a certain version of the small file. It
then follows the reference to the big file and writes that into your
working copy instead of the small file.

The big files are stored on a HTTP server or a shared network drive or
similar -- the idea being that you will setup a central server that has
enough disk space to keep all versions of the big files around. The
clients only download the one version of the big files they need.

Here are links to two such extensions which are used in production:

  http://mercurial.selenic.com/wiki/BfilesExtension
  http://mercurial.selenic.com/wiki/SnapExtension

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/mercurial/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20101003/d169f5b0/attachment.pgp