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

Re: ra_serf violating editor API restrictions

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2007-08-13 17:16:56 CEST

On Thu, 2007-08-09 at 14:27 -0700, Justin Erenkrantz wrote:
> No, I don't think you can get the performance benefits without
> violating this particular rule.

Huh. ra_svn is pipelined without violating this rule. It does fudge
with error returns (you don't generally get an error from the editor
operation which caused the error, because that would require a round
trip per operation), but it doesn't do out of order operations.

We've had this discussion before, but I never understood why it's
necessary to use multiple parallel connections to get good performance.
One connection with no waiting for round trips should be just as good.

On the other hand, I also sympathize with:

   <jerenkrantz> given that it has a parent_baton, it's a silly
                 restriction, imo

Those with very long memories may remember that back at the beginning of
my involvement with the project, I proposed throwing out the directory
batons because all they did was allow you to violate the API contract.
(At the time, I had been tasked with writing an "XML editor" which
absolutely required the depth-first constraints. We're not using that
editor any more, of course.) That would have made ra_serf's approach
merely impossible, which isn't necessarily a good outcome, but it
certainly would have avoided this ambiguous situation.

No strong opinion as to what to do now. I believe CMike's feature can
be written without the depth-first constraint; it just has to keep track
of batons and think a bit harder. We may have other editors which do
depend on the depth-first constraint; the reporter (commit) editor
might, for instance.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 13 17:15:19 2007

This is an archived mail posted to the Subversion Dev mailing list.