[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 comments

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-10-13 16:31:06 CEST

On Oct 13, 2004, at 9:17 AM, Garrett Rooney wrote:
> It's not totally pointless. Requiring a lock to be taken out also
> requires the pre-lock hook script to fire, which means that the
> administrator has the ability to say "you can't lock this file". That
> might be useful in some situations.

Another reason it's not pointless is that it's inherently part of the
UI to prevent people from wasting time.

The model is: somebody wants to change a file, then notices it's
read-only. "Oh", he thinks, "that's right, I guess I should lock this
thing first." The reward for running 'svn lock' is that the file
becomes read-write.

Sure, you could argue that there's nothing *techincally* gained by
requiring a lock before commit (since the server is ultimately
enforcing locks, not the client), but it's a fundamental part of the
"don't-waste-time-editing" system. The theory is that an administrator
would activate this read-only/must-lock-first behavior on all files
that are inherently unmergable.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 16:31:27 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.