[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r11284 - trunk/subversion/libsvn_ra_dav

From: <kfogel_at_collab.net>
Date: 2004-10-11 19:55:26 CEST

cmpilato@tigris.org writes:
> --- trunk/subversion/libsvn_ra_dav/commit.c (original)
> +++ trunk/subversion/libsvn_ra_dav/commit.c Thu Oct 7 16:20:48 2004
> @@ -131,6 +131,22 @@
>
> static const ne_propname log_message_prop = { SVN_DAV_PROP_NS_SVN, "log" };
>
> +static resource_t * dup_resource(resource_t *base, apr_pool_t *pool)
> +{
> + resource_t *rsrc = apr_pcalloc(pool, sizeof(*rsrc));
> + rsrc->pool = pool;
> + rsrc->revision = base->revision;
> + rsrc->url = base->url ?
> + apr_pstrdup(pool, base->url) : NULL;
> + rsrc->vsn_url = base->vsn_url ?
> + apr_pstrdup(pool, base->vsn_url) : NULL;
> + rsrc->wr_url = base->wr_url ?
> + apr_pstrdup(pool, base->wr_url) : NULL;
> + rsrc->local_path = base->local_path ?
> + apr_pstrdup(pool, base->local_path) : NULL;
> + return rsrc;
> +}

Needs documentation. (Yeah, ra_dav historically has been deficient in
that regard, but that doesn't mean we have to perpetuate the problem
with new functions :-) ).

In this case, although the function's behavior is fairly obvious,
documentation would clarify pool usage. Something like:

   /* Return a new resource that duplicates BASE. Allocate the new
      resource and everything inside it in POOL, such that if BASE's
      pool is not related to POOL, then freeing BASE's pool has no
      effect on the new resource. */

> static svn_error_t * simple_request(svn_ra_session_t *ras,
> const char *method,
> const char *url,
> @@ -352,7 +368,7 @@
> return SVN_NO_ERROR;
> }
>
> -/* add a child resource. POOL should be as "temporary" as possible,
> +/* Add a child resource. POOL should be as "temporary" as possible,
> but probably not as far as requiring a new temp pool. */
> static svn_error_t * add_child(resource_t **child,
> commit_ctx_t *cc,

Considering that callers are now using a new temp pool, as of this
commit, I think the second line of this comment is obsolete now :-).

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 11 21:44:59 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.