[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn eats all memory, OOM killer kicks in

From: <cmpilato_at_collab.net>
Date: 2002-04-15 18:01:43 CEST

"Marcelo E. Magallon" <marcelo.magallon@bigfoot.com> writes:

> >> cmpilato@collab.net writes:
>
> > > At this point I assume the repository has been corrupted. How can I
> > > verify or deny this?
> >
> > You could use the `svnadmin' and `svnlook' tools to see what your
> > youngest revision is, what paths exist in it, etc. That would be
> > really useful information.

I'm pretty sure I know what happened to you. The new commit process'
memory usage wasn't soooooo bad, up to the point just after the commit
succeeded -- then things took a turn for the REALLY BAD. In between
time the last `.' gets printed after "Transmitting..." and the time
`Committed revision XXX' shows up, your working copy is being updated
to reflect that all those added files are a) no longer added, but
regular working copy files, and b) have a revision number of XXX. The
problem is that this process itself (which we refer to as "revision
bumping") was eating up gobs of memory.

So, while your commit succeeded in the repository, your client was
Killed before the working copy was fully modified to reflect that it
*knew* your commit had succeeded (thus the reason why some of your
files were still marked for addition, and some weren't). Well, that's
just a bogus place to be from a working copy standpoint, as you can
imagine.

I am fixing our memory usage right now (actually, this fix is done,
I'm just recompiling and testing). Watch the svn@ list for the commit.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 15 18:04:35 2002

This is an archived mail posted to the Subversion Dev mailing list.