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

Re: svn commit: r37137 - in trunk/subversion: libsvn_fs_base tests/libsvn_fs_base

From: Paul Burba <ptburba_at_gmail.com>
Date: Tue, 5 May 2009 12:17:09 -0400

On Thu, Apr 9, 2009 at 12:27 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:

> ---------- Forwarded message ----------
> From: cmpilato_at_tigris.org
> To: svn_at_subversion.tigris.org
> Date: Thu, 9 Apr 2009 09:24:28 -0700
> Subject: svn commit: r37137 - in trunk/subversion: libsvn_fs_base tests/libsvn_fs_base
> Author: cmpilato
> Date: Thu Apr  9 09:24:28 2009
> New Revision: 37137
> Log:
> Attempt to button down the BDB backend's memory usage by allowing trail
> producers to tell that subsystem to discard all memory associated with
> the trail.
> Most of the time, this pool usage waste isn't a problem (because of
> better pool practices in higher layers).  But mod_dav and mod_dav_svn
> have notoriously wicked pool usage behavior, and I'm tired of having
> the theoretically niceties of our pool usage guidelines getting in the
> way of Subversion working.  Why should a simple 'svn ls -v' of a
> directory with 10,000 files exhaust all the memory on my 2Gb laptop?
> It shouldn't, ahd if this kind of change is what I have to do to get
> that leakage back down to "only" 339Mb, I feel compelled to do it.
> An arguably cleaner approach would have been to add a 'result_pool'
> argument to the txn_body_* function type which is the same pool passed
> to svn_fs_base__retry_txn().  That would allow the txn_body_*
> functions (which already operate with 'trail' and 'trail->pool' today)
> to use the 'result_pool' argument as a final destination for
> returnable stuff and 'trail->pool' for scratch work.  (And then
> do_retry() function would, of course, always whack trail->pool when it
> was finished with a trail.)  I've filed issue #3395 to track this
> possible future enhancement.
> Reviewed by:  gstein

Hi Greg,

Mike nominated this for backport to 1.6.2, it has two votes already.
I've taken a brief look at it last night, but before I dive in for a
deeper review I thought it worth checking to see if you, having
already reviewed the patch, were good for a +1 backport vote.


Received on 2009-05-05 18:18:13 CEST

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