On Mon, Jun 02, 2003 at 03:46:40PM -0400, Greg Hudson wrote:
> I'll take this as "not an objection" and re-prepare my patch for
> checkin.
Ah, right. Sorry I didn't clarify that.
> On Mon, 2003-06-02 at 04:23, Greg Stein wrote:
> > > Because of the incompatible ra_svn pipelining change, I'd like this to
> > > make it into 0.24, so that we don't break ra_svn compatibility for
> > > another two releases in a row. But apart from that, I can wait.
> >
> > Dang. Where's that email about people not wanting the protocol to alter the
> > APIs in Subversion... hmm... :-)
>
> Well, what you quoted is merely an argument for changing the
> scheduling. I think the API change is a good idea because the skelta
> decision shouldn't be happening on a per-file basis (or on both sides of
> the editor interface); the ra_svn inefficiency is merely fallout from
> that wart.
Yup. I've seen a number of things like that. Mike and I discussed others
options for the RA interface model. It would have made a lot of things quite
cool in any remoted scenario, but it wouldn't have helped the performance
that much, so we punted. We can save that for a v2 interface, and/or when
people start interacting directly with RA a bit more and use different
patterns that libsvn_client uses.
> > I also seem to recall a change to get
> > revnum info early (in a separate roundtrip(!)) because it couldn't happen
> > during a particular RA implementation's editor drive... :-)
>
> Would that be ra_local? Because we had set_target_revision well before
> I wrote any lines of ra_svn.
No, it was really early ra_svn. There was something about being able to pass
in INVALID_REVNUM to mean "head", but that horked up something because it
had to be resolved, yet ra_svn was trapped within an editor drive and
couldn't "escape" to run a distinct request. As a result, a lot of the
client code calls RA->get_latest_revnum() before doing any work.
*shrug*
It should mostly get cleared up as part of issue #??? (too many DAV
requests).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 2 21:58:48 2003