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

Re: svn commit: r23434 - in trunk/subversion: include libsvn_client libsvn_subr

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: 2007-02-20 19:15:51 CET

Ivan Zhakov wrote:
> On 2/20/07, Daniel Rall <dlr@collab.net> wrote:
>> On Mon, 19 Feb 2007, hwright@tigris.org wrote:
>> ...
>> > --- trunk/subversion/include/svn_opt.h (original)
>> > +++ trunk/subversion/include/svn_opt.h Mon Feb 19 19:45:21 2007
>> ...
>> > -svn_error_t *
>> > -svn_client__resolve_revisions(svn_opt_revision_t *peg_rev,
>> > - svn_opt_revision_t *op_rev,
>> > - svn_boolean_t is_url,
>> > - svn_boolean_t notice_local_mods);
>> ...
>> > --- trunk/subversion/libsvn_subr/opt.c (original)
>> > +++ trunk/subversion/libsvn_subr/opt.c Mon Feb 19 19:45:21 2007
>> > @@ -610,6 +610,33 @@
>> > }
>> >
>> >
>> > +void
>> > +svn_opt_resolve_revisions(svn_opt_revision_t *peg_rev,
>> > + svn_opt_revision_t *op_rev,
>> > + svn_boolean_t is_url,
>> > + svn_boolean_t notice_local_mods)
>> > +{
>> > + if (peg_rev->kind == svn_opt_revision_unspecified)
>> > + {
>> > + if (is_url)
>> > + {
>> > + peg_rev->kind = svn_opt_revision_head;
>> > + }
>> > + else
>> > + {
>> > + if (notice_local_mods)
>> > + peg_rev->kind = svn_opt_revision_working;
>> > + else
>> > + peg_rev->kind = svn_opt_revision_base;
>> > + }
>> > + }
>> > +
>> > + if (op_rev->kind == svn_opt_revision_unspecified)
>> > + *op_rev = *peg_rev;
>> > +
>> > + return;
>> > +}
>> ...
>>
>> If we're really going to drop the return value of SVN_NO_ERROR (which
>> we actually might not want to do in case a future variation on the
>> implementation needs it), we should drop that return statement, too.
>>
> Also is there any guarantee that any implementation of this function
> can be done without pool parameter in future? I'm not sure.
>

I'm trying to think of a scenario where we would need a pool parameter
in the future. The only thing that I can think of would be if the
svn_opt_revision_t structure was extended, and we needed to allocate
something to finish the assignment. In this case, though, we'd need to
rev the API anyway to use the new datatype.

Are there other scenarios where we might need a pool parameter?

I don't care either way, I'm just trying to understand the potential
scenarios a bit better.

-Hyrum

Received on Tue Feb 20 19:16:10 2007

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