Re: svn commit: r27780 - in trunk/subversion: include include/private libsvn_ra_local libsvn_repos mod_dav_svn svnserve

Blair Zajac <blair@orcaware.com> writes:
>> Also good. One could figure it out from reading the doc string and
>> from knowing that there is no way to get a pool given only an
>> svn_repos_t and an apr_array_header_t... but one shouldn't have to :-).
>
> Good point on that one. But couldn't the svn_repos_t store a pool to
> the pointer it was allocated in and use that to make a copy of the
> capabilities?

Hmm, yes, it could. I wasn't sure whether I really wanted to expand
the change to include that, though. It wouldn't help the current
callers, because they always set the capabilities right after creating
the svn_repos_t object anyway, so it's easy for them to give
everything the right lifetime. Felt like premature generalization...

Our guidelines advise in a general way against allocating foo in pool
and then storing foo->pool:

   http://subversion.tigris.org/hacking.html#apr-pools

Clearly, exceptions can be made, I'm just not sure this case calls for
it.

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 13 23:45:21 2007