On Thu, 2004-04-08 at 15:41, Ben Collins-Sussman wrote:
> The roadmap is:
>
> * for now, cmpilato's function will only verify that that the path in
> rFUTURE is on the same line of history as our peg. If so, great. If
> not, return an error about the rFUTURE object being unrelated.
>
> * someday, when we're able to search forward in history, cmpilato's
> function will only follow moves, and still return exactly one path from
> rFUTURE. (or NULL/error if the object doesn't exist in rFUTURE.)
Here's a followup to this plan. (Shlomi Fish: this mail is for you!)
Once I've got the new client function working using only RA->get_logs(),
I'll improve it so that it first attempts to use Shlomi's new RA
function. If the server doesn't have the new fs function, we'll get an
error back. In that case, the new client function will "fall back" to
using RA->get_logs(). This solves the potential compatibility problem
of a 1.1 client talking to a 1.0 server.
So Shlomi, go ahead and continue writing your new RA and fs functions.
As cmpilato pointed out in an earlier email, he'd like the RA interface
to be a bit more complicated than the client interface:
Requirement #1:
The client interface takes a (peg-rev, peg-url) pair, as well as two
revisions X and Y. It returns a URL for X and a URL for Y. The RA
interface, however, should take a list of revisions, and return a list
of corresponding URLs. We don't want to limit the interface to just
single X and Y inputs. In other words, the caller be able to should
ask, "tell me where this object exists in *all* these revisions."
Requirement #2:
If svnserve or apache doesn't have the new fs function, throw a specific
error so the client can trap it and fall back to RA->get_logs().
Requirement #3:
Remember, for now, we can't actually search future history. If the new
fs function receives a target revision larger than the peg-revision, do
ghudson's "sanity check": just verify that whatever exists in the
future revision is the same object as the peg object.
I'm off to work on the client function for now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 12 17:21:41 2004