[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: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2007-08-09 23:27:01 CEST

On 8/9/07, C. Michael Pilato <cmpilato@collab.net> wrote:
> with this asynchronous, parallelized activity. But here's my real concern,
> though: we have API rules and promises associated with them, and this
> violation could cause problems for third-party consumers of the RA
> interface. I don't think we should cavalierly disregard the API rules in
> this fashion, even if there are performance benefits to be had. And I
> suspect that we could still be getting most of these performance benefits
> anyway without violating the editor rules.

No, I don't think you can get the performance benefits without
violating this particular rule. At the time, we looked at all of the
implementations we had and all of our editors would not be affected by
relaxing this constraint.

The core issue is that we parallelize what files we checkout/update
across a number of connections. In order to adhere to this particular
constraint, we can't parallelize outside of a single directory at any
given time as this editor rule requires that only one directory (and
all children files) be open at a time.

If you see a way to efficiently parallelize checkouts across multiple
directories *and* adhere to this constraint, I'm all ears. But, when
we discussed this way back yonder (don't recall if it was on IRC or
email at the time), there didn't seem to be any way around it and most
felt that the constraint could/should be relaxed. -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 9 23:25:10 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.