Ben Collins-Sussman wrote:
>
> On Oct 20, 2004, at 3:39 PM, Garrett Rooney wrote:
>
>> Ben Collins-Sussman wrote:
>>
>>> So I suppose mod_dav_svn can have another private db table (like the
>>> activities.db) which can store lock-expiration times. Whenever a
>>> client mentions a lock, mod_dav_svn can compare the lock-expiration
>>> time (if it exists) with the lock's creation timestamp, and
>>> "auto-release" the lock.
>>
>>
>> That doesn't work so well for repositories that can be accessed by
>> more than one RA layer. Someone takes out a 5 minute lock over
>> mod_dav_svn, then nobody ever uses the http:// interface again, the
>> lock stays there forever, or at least until someone breaks it
>> manually. That doesn't seem right...
>>
>
> Hm, I suppose you're right. Maybe this means that lock expiration
> needs to be a 'core' feature in libsvn_repos, common to all RA
> accesses. But we still don't have to expose that feature on the
> client side.
In libsvn_(repos|fs), but /not/ in the RA layers. That's the whole point.
We need it in the repos/fs layer so that mod_dav_svn can set the
timeouts and so that they get cleaned up automagically, but even ra_dav
shouldn't issue lock requests with timeouts. We'll support lock timeouts
in mod_dav_svn for non-Subversion clients, such as MS Office. No
Subversion client should ever issue such a request.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 20 23:55:02 2004