[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: Daniel Patterson <danpat_at_danpat.net>
Date: 2004-10-19 23:35:37 CEST

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!

   People *are* going to lock things they don't need to lock, in
   great swathes across their WC's. Then, they're going to make one
   or two changes, commit those files and unlock *just those files*,
   leaving everything else locked.

   Then, they're going to go on vacation.

   Heck, where I work, people
   constantly (after at least a couple of years of begging, pleading
   threatening, etc) commit files one at a time, commit debugging code,
   files specific to their personal environment, temp files, object
   files, etc.

   I think it's reasonably sensible to at least have the ability for
   the repository to slowly (as locks expire) restore itself to a state
   where everyone can work again. Sure, the admin can break locks
   (or maybe users can too, depending on policy), but if the admin
   is away, and the policy is "users can't break locks", then having
   locks expire may be a saving grace.

   I think lock expiry is a counter-measure for users who don't
   communicate sufficiently. It makes their lack of communication their
   problem, not everyone elses (i.e. they have to deal with the
   conflicts and apparent hijacks when they return from vacation,
   which is their own fault for leaving locked files and walking out).

   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").


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 19 23:38: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.