hg pull runs out of memory

[Hertroys A.]

I worked around the problem by exporting the changes (text only) from changesets 1110:tip, updating the main repo back to rev 1109 (the changeset before the large files went in), importing the changesets in my local repo and pushing those to the central repo again.

Now I have a tip without the problematic files, and a branch (which I tagged as broken) where the changes that included those files are.

I did seem to need to re-clone the main repo to get the new branch in, not sure why, but hg pull seemed to fetch the bad branch instead (out of memory again).

> -----Original Message-----
> From: mercurial-bounces at selenic.com [mailto:mercurial-
> bounces at selenic.com] On Behalf Of Hertroys A.
> Sent: Wednesday, April 25, 2012 2:40 PM
> To: Andreas Tscharner; mercurial at selenic.com
> Subject: RE: hg pull runs out of memory
> 
> > On 25.04.2012 11:24, Hertroys A. wrote:
> > > Hi,
> >
> > Hello,
> > >
> >
> > [snip]
> > > I managed to isolate the change-set (1110) and it contains a couple of
> > > large binary files that were added accidentally. They were removed again
> > > a couple of change-sets later (1112). My clone is updated to 1109 now,
> > > but I can’t get it past there!
> >
> > First of all: You have to use a machine (once!) that has enough memory
> > to do that.
> 
> I found a machine with more memory (one of our servers, it has 4GB instead
> of 2), but it aborted the pull in the same way. I don't think the system actually
> runs out of memory, even on my desktop it's only using about 1.5GB of the
> 4GB I have available (incl. swap) when it aborts. It seems more like I'm
> running into a process limit or something. Is there such a thing as a memory
> limit in Windows for processes, or DOS prompts specifically?
> 
> Or perhaps I need more memory than our (mainly 32-bit) systems can
> address, in which case my options are limited to a few production servers :(
> 
> I tried increasing swap on my desktop system to 8GB, but that didn't make
> any difference either. Of course that's beyond the address space of a 32-bit
> machine, I'm not sure how well (that sounds almost amusing) Windows can
> handle that.
> 
> Why does Mercurial need that much memory to pull in a binary file anyway?
> There doesn't seem to be any benefit in keeping it in memory. Can that be
> prevented somehow, perhaps (after they've been added to the repo,
> obviously)?
> 
> Regards,
> Alban.
> 
> 
> alban.hertroys at apollovredestein.com
> T:
> 
> Apollo Vredestein B.V. - P.O. Box 27 - 7500 AA Enschede - The Netherlands -
> Chamber of Commerce number 34223268 -
> http://www.apollovredestein.com
> 
> The information contained in this e-mail is intended solely for the use of the
> individual or entity to whom it is addressed and others authorized to receive
> it. You are hereby notified that any disclosure, copying, distribution or action
> in relation to the contents of this information is strictly prohibited. If you are
> not the intended recipient, please delete this message and any attachments
> and advise the sender by return e-mail. The confidentiality of this message is
> not warranted. Apollo Vredestein B.V. rules out any and every liability
> resulting from this or any other electronic transmission.
> --------------------------------------------------------------------------
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial