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

Re: Revised Proposal: Improved locking implementation for fsfs

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-01-06 16:51:27 CET

On Thu, 6 Jan 2005, John Szakmeister wrote:

> Peter N. Lundblad wrote:
> > On Thu, 6 Jan 2005, [UTF-8] Branko �^Libej wrote:
> >
> >
> >>Brian W. Fitzpatrick wrote:
> >>
> >>In short, you avoid quadratic I/O behaviour here in exactly the same way
> >>as we did in the WC -- by caching the entries files. I'm not sure if
> >>this is a valid thing to do in the face of possibly multi-process access
> >>to the FS, though.
> >>
> >
> > As long as we think that our current APIs, where each lock/unlock requires
> > at least one network round-trip, I think we shouldn't care very much about
> > this. Locking 10,000 files in one directory is really a corner case, isn't
> > it?
> I'm not sure about that. I currently work with a customer who has a
> pretty large setup, and they're dying for locking to get into place.
> They've already asked me several times about being able to have locks on
> every file in the repository. I would not put it past them to hit this
> case... and to do it the first time they get locking up and running.
And they want to lock all files at a time? This is more a question about
whether our lock/unlock-taking-one-path-at-a-time API is appropriate. If
we want to handle locking hundreds of files at the same time
appropriately, we need "lock/unlock these paths" APIs instead. I think DAV
will require one round-trip per locked path anyway.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 6 17:04:43 2005

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.