Greg Stein wrote on Fri, Mar 23, 2012 at 22:46:43 -0400:
> On Mar 23, 2012 7:16 PM, <danie...@apache.org> wrote:
> >...
> > +++ subversion/trunk/subversion/libsvn_fs_fs/tree.c Fri Mar 23 23:15:34
> 2012
> ...
> > + if (kind == svn_node_dir)
> > + {
> > + apr_hash_t *entries;
> > + apr_hash_index_t *hi;
> > + apr_int64_t children_mergeinfo = 0;
> > +
> > + SVN_ERR(svn_fs_fs__dag_dir_entries(&entries, node, pool, pool));
> > +
> > + /* Compute CHILDREN_MERGEINFO. */
> > + /* ### TODO: iterpool? */
> > + for (hi = apr_hash_first(pool, entries);
> > + hi;
> > + hi = apr_hash_next(hi))
>
> I think the iterpool is a must-have; otherwise, it appears the entire tree
> (given the recursion) for a revision falls into that outermost iterpool of
> verify's caller.
>
The recursion here touches every changed path, every ancestor of
a changed path, and every immediate child of one of the preceding.
Usually we allocate all the CHANGED_PATHS information in a single pool,
but here we touch every immediate child of every ancestor too. Iterpool
it is then.
> >...
>
> Cheers,
> -g
