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

Re: subversion 1.3.1 + apr 0.9.7 = memory leak?

From: David Young <dyoung_at_pobox.com>
Date: 2006-05-05 05:11:49 CEST

On Thu, May 04, 2006 at 03:06:19PM -0700, Eric Gillespie wrote:
> "Garrett Rooney" <rooneg@electricjellyfish.net> writes:
> > On 5/3/06, David Young <dyoung@pobox.com> wrote:
> [...]
> > > When I run commands such as 'svn co' and 'svn status -u' on the
> > > repository, they take several minutes to run (i.e., too long), and svn's
> > > memory usage climbs to 150MB, which seems unusually high. This is not
> [...]
> > Operations on large working copies (including checkout and status)
> > will use amounts of memory proportional to its size, due to the
> > caching of information about the entries in each directory.
> Hmm. Only the entries for the directory currently being scanned
> and all its parents need be in memory at once. There should be a
> subpool for each directory, i would think. If it's growing
> without bound, it sounds to me like *all* entries are staying in
> memory. In other words, given
> wc
> wc/bin
> wc/bin/ls
> wc/bin/sh
> wc/bin/ls entries should be in a pool that is freed before moving
> on to wc/bin/sh.

I am now reading the code, and I cannot find any indication that it isn't
(supposed) to work just as you say. Is Subversion known to leak entries
by design? Where does this caching occur?


David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 5 05:14:01 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.