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