[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: Branko Čibej <brane_at_xbc.nu>
Date: 2005-01-09 21:37:39 CET

Peter N. Lundblad wrote:

>On Thu, 6 Jan 2005, John Szakmeister wrote:
>
>
>
>>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.
>>
>>
>>
>Just to make it clear. The current proposal for lock implementation in
>fsfs will not have quadratic time complexity for lock, since you don't
>need to rewrite the whole file. Unlock is quadratic. If we add APIs to
>lock/unlock many paths at a time, we can rewrite each directory file once
>without changing the file format. So that will be linear in the number of
>paths then.
>
>BTW, it might be a good idea to have an unlock array of paths function in
>the repos/fs APIs for unlocking commits. But that can wait until after 1.2
>IMO. Then we know if it makes a big difference in practice.
>
>
I think it would be simpler for the locking API to only work with arrays
of locks, at least in the RA layer. It's a given that, if every
lock/unlock causes a network roundtrip, then using an array will be
visibly faster even if you only operate on two locks at a time. It
doesn't really make sense to have only the slower method in 1.2 and then
make people wait until 1.3 for the more optimal version.

BTW, can you lock several files with a single DAV request?

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jan 9 21:37:24 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.