Locking: server-side implementation strategy

[Ben Collins-Sussman <su...@collab.net>]

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.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Locking: server-side implementation strategy

[Branko Čibej <br...@xbc.nu>]

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