On Tue, 20 Feb 2007, Hyrum K. Wright wrote:
> 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.
I can't think of any off-hand.
These suggestions are more from our experience with the need for
similar tweaks with other APIs in the past, more than with any
possible situations we forsee with this particular case.
- application/pgp-signature attachment: stored
Received on Tue Feb 20 22:52:14 2007