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

Re: Locking: server-side implementation strategy

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-10-29 09:00:20 CEST

Ben Collins-Sussman wrote:

>
> On Oct 28, 2004, at 2:50 PM, sussman@tigris.org wrote:
>
>> Author: sussman
>> Date: Thu Oct 28 14:49:59 2004
>> New Revision: 11653
>>
>> Added:
>> trunk/notes/locking/locking-implementation.txt
>> Log:
>> * notes/locking/locking-implementation.txt: new file.
>>
>
> I've started filling in a roadmap for implementing locks on the
> server-side, mostly based on list discussions we've had already.
> Take a look. Tear it apart.

C.4. I just want to point out that a prefix search should be no worse
than O(log N) on the number of locks. Call that an acceptance criterion
for any locking implementation. :-) Of course BDB will do that for you
if you store the locks in a table.

E.2: /Must/ we call it "svnadmin release"? I'd have thought "svnadmin
unlock" would be a more logical choice...

I see a useful role for script that can be called from the lock hook
scripts and uses the mod_authz_svn config file to determine who can
break or steal locks, and an extension to mailer.py that can handle
post-[un]lock notifications. I'm not saying this should be mentioned in
the locking design doc.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 29 09:00:44 2004

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.