[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: John Szakmeister <john_at_szakmeister.net>
Date: 2005-01-06 20:27:33 CET

Ben Collins-Sussman wrote:
> On Jan 6, 2005, at 9:28 AM, 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.
> I think what they're saying is: "we'd like to *require* locks on every
> file in the repository before editing", right? Not that they literally
> want to attach an active lock to every file in the repository at the
> same time.
> In other words, when they import a project, the first thing they'll do
> is attach the new 'svn:needs-lock' property to every file. Then working
> copies will show every file as read-only all the time, and user will
> have to 'svn lock' to begin edits on any file.

They'd like that too, as well as the ability to automatically add
svn:need-locks to new files. :-) But no, I think these guys will take
out a lock on hundreds/thousands of files at once. They're a bit of an
edge case, so I wouldn't worry over it. I just wanted to point out that
 I know of at least one team that might do such a thing.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 6 20:29:08 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.