On Wed, May 6, 2009 at 1:38 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> Hi Greg and Bert,
>
> To clarify, the "child" structures, svn_client__merge_path_t, do not
> carry their own pools.
>
> And no, we don't want to allocate CHILD->IMPLICIT_MERGEINFO in the
> subpool, these children svn_client__merge_path_t elements in the
> CHILDREN_WITH_MERGEINFO array need to live as long as the subpool that
> libsvn_client/merge.c:do_merge() passes to do_directory_merge(). The
> fact that I was passing the subpool to the get_full_mergeinfo() call
> when processing reverse merges is definitely wrong, our test suite
> simply didn't expose it (as Bert noted, using a subpool for forward
> merges will cause many tests to fail).
>
> Bert -- Re your comment 'It should probably walk the ancestors instead
> of just the parent': inherit_implicit_mergeinfo_from_parent() will get
> PARENT->IMPLICIT_MERGEINFO if that was deferred, so we only need look
> to the parent (unless I am not correctly understanding your concern?).
>
> Greg -- I see now that we are using the double pool ('result_pool' and
> 'scratch_pool') approach quite extensively. I have not been doing
> this, but I adjusted Bert's patch to use this approach and will use it
> myself going forward.
>
> Other than the double pool, the only other changes I've made to Bert's
> patch are to the doc string for ensure_implicit_mergeinfo().
>
> Paul
Committed to trunk r37618, nominated for backport to 1.6.x.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2083432
Received on 2009-05-06 20:29:20 CEST