On Sat, Nov 15, 2008 at 11:36 AM, Blair Zajac <blair_at_orcaware.com> wrote:
> On Nov 15, 2008, at 1:56 AM, Greg Stein wrote:
>> On Fri, Nov 14, 2008 at 5:46 PM, <blair_at_tigris.org> wrote:
>>> ...
>>> +++ trunk/subversion/libsvn_fs_fs/tree.c Fri Nov 14 17:46:41 2008
>>> (r34213)
>>> ...
>>> @@ -1681,23 +1691,23 @@ svn_fs_fs__commit_txn(const char **confl
>>> was the target of the merge (but note that the youngest rev
>>> may have changed by then -- that's why we're careful to get
>>> this root in its own bdb txn here). */
>>> - SVN_ERR(get_root(&youngish_root_node, youngish_root, pool));
>>> + SVN_ERR(get_root(&youngish_root_node, youngish_root, iterpool));
>>
>> This SVN_ERR might exit the function without doing the pool destruction...
>>
>> (same with others, of course)
>
> Yeah, I figured that was fine. We don't clean up most pools in case of an
> error.
>
> Should we change it?
The correct answer is "yes", but the real answer is "nah".
Theoretically, the caller might ignore the error, so you end up with
an extra pool hanging around longer than expected. But typically, the
error will propagate "all the way" and the pool will disappear.
While not The Best Answer, I'd go ahead and leave it as-is.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-16 04:21:30 CET