On Jan 6, 2005, at 9:28 AM, John Szakmeister wrote:
> Peter N. Lundblad wrote:
>> On Thu, 6 Jan 2005, [UTF-8] Branko ¡Z^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.
---------------------------------------------------------------------
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:43:15 2005