Sander Striker wrote:
>>From: Mark Benedetto King [mailto:mbk@lowlatency.com]
>>Sent: Wednesday, October 13, 2004 1:54 PM
>>
>>
>
>
>
>>Well, one counter argument is that many people will forget to release
>>their locks.
>>
>>
>
>As long as locks are breakable/stealable, I don't really see the problem.
>
>
I do. The ability to steal locks will (one day) be controlled by ACLs.
It is entirely reasonable in many environments to not allow every junior
hacker to break other people's locks. Therefore "ci" should release
locks by default.
Another reason for unlock-by default is that a commit usually means one
has finished with a particular task.
Other version control systems release locks by default on commit, and
have years and years of user experience behind that decision. There's
_also_ a lot to say about the principle of least surprise.
Which reminds me of the "lock updated by default" issue. Again, the most
common use case is "get the latest version of the file and lock it".
We'll have to have a simple way to do this. Since we cannot change the
behaviour of "svn up", the options are:
* svn update --lock
* svn lock --update
* svn lock
For brevity, "svn lock" should also update the file.
However, that would break symmetry with unlock and commit; I'm assuming
it's totally unreadonable to expect that "svn unlock" would commit a
file; and the pair (svn lock, svn commit) isn't intuitively complementary.
So to keep the UI symmatrical, the behaviour should be:
* The commands "svn lock" "svn unlock" only change the lock status
of a file. If the file isn't up to date in the WC, "svn lock" can
behave in on of two ways:
o refuse to lock the file without --force
o lock the file anyway, but a subsequent commit will fail
unless the file has been updated in the meantime (that is,
the file's BASE must be the same as HEAD at the time of lock
creation)
* "svn update" accepts a --lock flag, meaning "get the latest
version and lock it" (but only valid without -r or with an
equivalent of -rHEAD)
* "svn commit" also accepts --lock, meaning "commit but keep the
lock". By default, "svn commit" releases all locks.
The open question is whether "svn lock --update" should mean the same as
"svn upate -rHEAD --lock"
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 15 00:53:17 2004