[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: Greg Stein <gstein_at_gmail.com>
Date: Tue, 5 May 2009 18:20:16 +0200

It never hurts for a fourth review, but yah... I'll +1 this sucker this evening.

Thx!
-g

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
>>
>> 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.
>
> Paul
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2070651
Received on 2009-05-05 18:20:48 CEST

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

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