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

Re: Locking UI comments

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-10-15 00:53:10 CEST

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
    * "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

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.