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

Re: [PATCH] First cut at 1954 solution

From: VK Sameer <sameer_at_collab.net>
Date: 2004-12-10 06:05:44 CET

Sorry, had Evolution problems (still in the primordial ooze :)) and this
didn't get sent.

On Tue, 2004-12-07 at 07:50, C. Michael Pilato wrote:
> VK Sameer <sameer@collab.net> writes:
> > OK, I'm open to suggestions :) If it helps any, the first comment is
> > going to go away partially as per Philip Martin's and Peter Lundblad's
> > comments.
> Yeah, I think someone else suggested that simply defining what a valid
> path is would do the trick (instead of detailing the algorithm for
> detecting invalid ones).
[I'm still trying to decide whether to answer each email and repeat or
consolidate and risk losing part of the thread info somewhere.]

OK, have changed as per Karl's suggestion.

> I'm a big fan of APIs that list every return value, but haven't the
> time or energy to retroactively do this for Subversion. That said,
> we are pretty good about listing return codes that we anticipate
> callers explicitly testing for. I anticipate callers testing the
> return value of this function (beyond just "is errorful").
There are 2 functions now, one that just returns a boolean value and
another that returns an error, again per Karl's suggestion.

> In fact, since the goal of the function is to answer a question -- "Is
> this path a valid Subversion path?" -- we may instead want this
> interface to take an svn_boolean_t * parameter which is populated with
> TRUE or FALSE to yield the answer, and leave all error conditions to
> mean, "Something bad happened that prevents me from answering your
> question." Besides a better semantic feel, this would also prevent
> Subversion from instantiating an error that the caller might choose
> not to use (and have to tear down).
Makes sense. I think having 2 functions as mentioned above covers your

> > > Also, we don't generally pass lengths with our paths.
> >
> > I can remove that if that is the general policy.
> Yep, that's the general policy.

OK, done.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 10 06:07:07 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.