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?
Dave
--
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