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

Re: RFC: svn_ra_get_locations2(), or a new function? And then some.

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-10-09 22:34:41 CEST

"C. Michael Pilato" <cmpilato@collab.net> writes:
> At the end of the conversation I got the sense that folks didn't care if I
> moved the logic into the RA loader so that API would be more robust. But
> the API docs as written promise that it returns SVN_ERR_RA_NOT_IMPLEMENTED
> when the server doesn't support it, and so my question here is: is that to
> be interpreted as a binding promise against which callers can be expected to
> code, or is it simply informational and subject to change? (Because if we
> move the fallback logic into the RA layer, there's no reason for it to ever
> return the SVN_ERR_RA_NOT_IMPLEMENTED, even if the *server* can't answer the
> question.)

I think it's fine to stop returning SVN_ERR_RA_NOT_IMPLEMENTED.

As a practical matter, the purpose of that kind of promise is merely
to alert callers to be ready for an SVN_ERR_RA_NOT_IMPLEMENTED error,
not to give them some weird back-door way to derive information about
what kind of server they're talking to. Anyway, in a sense, if you
can get the answer by talking to the server, then the server *does*
support it -- even if you had to do a funny little dance to get the

It might be good to change the doc string to note all this, but no API
rev is necessary, IMHO.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 9 22:35:32 2007

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.