I've been pining for a particular RA interface for some time, and now my
work on issue #2953 gives me a great excuse to add it. Basically, what I
need is a function which can return the various changes in a path's location
over time, and the revisions in which those location changes took place.
It's sorta like svn_ra_get_locations(), and sorta like svn_ra_get_log().
But the former is unable to answer the question, and the latter does too
much server-side work and is unnecessarily verbose. Think 'svnlook
history', minus the revisions where the location didn't change, plus
indications of historical gaps due to copies where TGT-REV - SRC-REV != 1.
Anyway, my question is, should I rev svn_ra_get_locations() and add a flag
which toggles it between "fill in the locations for the request revisions"
and "fill in all the location changes between a pair of endpoints" modes, or
just add a new RA API? I'm heavily leaning toward the latter, possibly
named svn_ra_get_history(), but wanted to poll for other opinions first.
Secondarily, I'll inevitably need to write compat code for issue #2953 to
handle the case where this new API (or new form of an old API) doesn't work.
Now, I noticed the other day that svn_ra_get_locations' compat fallback
code doesn't live in the RA layer, but as a helper function in
libsvn_client. There's a great that that's my own fault, but it caused me
to strike up a conversation about the matter in IRC. My question there was
basically, "Why can't the compat fallback logic for svn_ra_get_locations()
live in the RA loader library, shared across the various RA implementations?
(And I asked, of course, because if the answer was, "No reason at all", I
was ready to move it there.) Someone argued that the decision to use
fallback code should be given to the caller (because the fallback code might
be less performant); I argued that callers call APIs because they want
answers to specific questions, and the underlying mechanism for answering
the question is always a black box anyway, so why not provide those answers
when we have ways to do so regardless of the performance costs.
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.)
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Tue Oct 9 22:16:58 2007