It never hurts for a fourth review, but yah... I'll +1 this sucker this evening.
On Tue, May 5, 2009 at 18:17, Paul Burba <ptburba_at_gmail.com> wrote:
> 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
>> 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:20:48 CEST