On Wed, Aug 12, 2009 at 20:16, Hyrum K. Wright<hyrum_at_hyrumwright.org> wrote:
>...
> +++ trunk/subversion/libsvn_client/merge.c Wed Aug 12 11:16:02 2009 (r38702)
>...
> @@ -3675,8 +3677,8 @@ find_gaps_in_merge_source_history(svn_re
> peg_rev.value.number = young_rev;
> SVN_ERR(svn_client__get_history_as_mergeinfo(&implicit_src_mergeinfo, url,
> &peg_rev, young_rev, old_rev,
> - ra_session, NULL,
> - merge_b->ctx, scratch_pool));
> + ra_session, merge_b->ctx,
> + result_pool));
Why did the pool change here?
>...
> +++ trunk/subversion/libsvn_client/url.c Wed Aug 12 11:16:02 2009 (r38702)
> @@ -46,9 +46,16 @@ svn_client_url_from_path(const char **ur
> apr_pool_t *pool)
> {
> svn_opt_revision_t revision;
> + svn_client_ctx_t *ctx;
> +
> + SVN_ERR(svn_client_create_context(&ctx, pool));
> +
> + if (!svn_path_is_url(path_or_url))
> + SVN_ERR(svn_dirent_get_absolute(&path_or_url, path_or_url, pool));
> +
> revision.kind = svn_opt_revision_unspecified;
> return svn_client__derive_location(url, NULL, path_or_url, &revision,
> - NULL, NULL, NULL, pool);
> + NULL, ctx, pool, pool);
> }
Seems a bit "dangerous" to leave this ctx around waiting for the pool
to be cleared. Couldn't we end up with some dangling handles on DBs?
>...
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383061
Received on 2009-08-13 00:33:28 CEST