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

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.

Same.

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"

Cheers,
-g

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