"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
information.
It might be good to change the doc string to note all this, but no API
rev is necessary, IMHO.
-Karl
---------------------------------------------------------------------
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