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

Re: Locking functional spec: timeouts

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-10-20 01:32:26 CEST

On Tue, 2004-10-19 at 17:35, Daniel Patterson wrote:
> Greg Hudson wrote:
> > Not really. I think they'd be more likely to appreciate a locking
> > system which didn't confuse them by talking about features like expiry
> > which they don't need.
> I think you underestimate the forgetfulness of the Junior Programmer!

No... but I wouldn't expect them to use lock timeouts either. And I
would expect that, in environments where people lock things and forget
to unlock them, the system would be configured to allow people to steal
each other's locks.

Just because we can imagine someone setting up a repository such that
people can't get work done in it is not an excuse to keep adding feature
after feature to mitigate the harm.

> Perhaps lock expiry can be turned on as a file property,
> like 'svn:lock-expiry-time' or something (make it optional, or
> default to "-1").

Now you want to complicate the system even more, by making lock expiry
times depend not just on the lock request (which is how it works in DAV)
but also on repository properties.

We have a responsibility to help people do what they want, but we also
have a responsibility to keep things simple by not providing features
which only a tiny fraction of users would use.

(Just in case anyone's lost track, I'm not opposed to implement lock
timeouts at all; we need them for good DAV support. I'm opposed to
making them visible via the command-line client, the libsvn_client or
libsvn_ra APIs, or the ra_svn protocol.)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 20 01:33:07 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.