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