When hg push --chunked still throws abort: out of memory what should you do? - Kiln Knowledge Exchange

When hg push --chunked still throws abort: out of memory what should you do?

2010-05-12T18:11:19Z

Thanks in advance for your help,

I have contacted FogCreek / Kiln, who directed me to this --chunked option {http://kiln.stackexchange.com/questions/396/what-if-im-having-trouble-importing-a-very-large-repository}... but it still does not seem to work... they suggested I try posting here to see if the community has any suggestions.

I have a tried the hg push --chunked http://{my kiln repositry} command only to get the following results: searching for changes searching for changes searching for changes abort: out of memory

We do have some large files checked into our repository - in particular .net framework 3.5 install, msde ect... which subversion handled no problem.. I saw a post that said that Hg will run out of memory on 10 meg file if the machine doing the push has 2 gig of ram or less... could that be affecting this? Is there any work around for large repositories with large files?

Any ideas?

-Deva

Answer by Benjamin Pollack for When hg push --chunked still throws abort: out of memory what should you do?

2010-05-12T20:48:46Z

Mercurial can handle small binary files just fine; in fact, we have a lot of them (some not really that small, in fact) in Kiln's own repository. The problem comes because Mercurial requires roughly 2 * sum(file sizes) RAM to make a new changeset. Since Tortoise uses a 32-bit version of Mercurial, that means that commits need to be less than about 500 MB each for Mercurial to deal with them. Do you know whether you're over that limit?

ANSWER: I spoke to Deva on the phone. One of his changesets was well over 500 MB all by itself, which was indeed causing the problem. There were two parts to the solution:

Push from a 64-bit machine.
Bypass Kiln entirely for the initial push, since Kiln was running on a 32-bit machine.

All of us on the Kiln team are keenly aware that Mercurial's handling of large binaries needs to be improved, and we're actively working on it right now. Stay tuned for announcements on that front over the next several months.