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

Re: svn commit: rev 205 - trunk/subversion/libsvn_wc

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-10-04 11:59:06 CEST

On Wed, Oct 03, 2001 at 07:10:13PM -0500, cmpilato@tigris.org wrote:
> Author: cmpilato
> Date: 2001-10-04 00:10 GMT
> New Revision: 205
> Modified:
> trunk/subversion/libsvn_wc/questions.c
> trunk/subversion/libsvn_wc/status.c
> Log:
> Sorry, but 10 megs of memory just to run `svn st' on the subversion
> source tree is ridiculous. This brought my test case down below 400k.
> * subversion/libsvn_wc/questions.c
> (svn_wc_text_modified_p, svn_wc_props_modified_p,
> svn_wc_conflicted_p, svn_wc_has_binary_prop): Use a subpool, and
> destroy it when we're done. For crying out loud, we're returning
> data allocated outside the function. Also, use the SVN_ERR macro.

When SVN_ERR kicks in, you aren't tossing the subpool. That could be
problematic if the caller ignores your error return for some reason and
decides to just keep processing.

> (svn_wc_statuses): Use a subpool for all non-hash-related
> allocations, destroying it when we're done. Also, use the SVN_ERR
> macro.


Easiest solution is to create a new function and put the pool create/destroy
in there, and have it call the existing functions (passing the subpool).
That would allow the existing functions to continue using SVN_ERR.

Alternatively is a more complex SVN_ERR type macro, or manual "err = x; if
(err) goto cleanup; ... cleanup: svn_pool_destroy(subpool); return err"


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:44 2006

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.