Garrett Rooney <rooneg@electricjellyfish.net> wrote on 10/20/2004 04:39:22
PM:
> 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...
Maybe I differ with ghudson on this, I am not sure. Assuming we need to
support lock timeouts for DAV, then I would think that the lock "database"
for lack of a better term, would need to include an expiration date/time.
When any client, other than DAV, acquired a lock, the date/time would be
some "permanent" date like 12/31/9999. When any code, regardless of UI,
checked the database to see if a file were locked, it would always
consider the expiration date/time. So DAV locks could expire in any UI
without needing a daemon to get rid of them.
I wouldn't consider this "polluting" the code base, although I do not know
enough to know the impact, and it leaves the door open to create a UI for
setting the expiration in the future from the svn client. Although, I
still see little value in that. If this has to be supported for DAV,
though, I agree the lock ought to be supported properly in all UI.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 20 22:55:41 2004