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

Re: [Locking] commits and unlock (revisited)

From: Walter Nicholls <walter.nicholls_at_cornerstone.co.nz>
Date: 2005-02-23 00:55:31 CET

C. Michael Pilato wrote:

>"Brian W. Fitzpatrick" <fitz@collab.net> writes:
>> a) Upon commit, unlock all locked files in TARGETS
>> c) Upon commit, unlock nothing
BOTH! and I'm serious. These are two solutions to two separate use cases.

Here's my workflow
1. Start working - lock a few files and start modifing
2. Back up my current work to the repository, but I'm still working on it
      This is (c)
3. Finished working and move on to something else
      This is (b)

Is there a problem with EITHER
 - adding a new command (commit-and-unlock)
 OR forcing the user to specify if SVN COMMIT detects that locks are
present (in scope)?

SourceSafe (for example) offers both options. (a) is SS CHECKIN
<filelist>, (c) is SS CHECKIN <filelist> -K (not that I ever used the
sourcesafe command line).

In the interests of caution and backward compatibility I suggest the
Commit unlocks nothing, AND warns that locks still exist
I would prefer a commit-and-unlock command, but if you guys would prefer
not to add a new command (or can't think of a suitable name! I can't)
then commit --unlock would still provide the functionality in one line.
"svn cu" would be a very handy shortcut.

I already forget to SVN ADD often enough, I don't need to forget to SVN
UNLOCK either. But I don't mind retraining myself to type SVN CU
instead of SVN CI

The consequences of commit unlocking files I need to keep locked are far
far worse than the consequences of commit not unlocking a file. Usually
when I make a mistake like this, I realise it before my fingers have
left the keyboard (but after pressing the Enter key).

And I believe this discussion applies equally to SVN REVERT, however I'm
far more cautious when going near that command. Once again, there are
two use cases - I want to get back what the repository says and keep
working (SVN REVERT should unlock nothing), or I want to abandon what
I'm doing entirely (SVN REVERT --unlock). It also applies to some
extent to UPDATE.

I posted on this subject end of last year if you want more waffle/detail
from me (http://svn.haxx.se/dev/archive-2004-12/0824.shtml). It all
still seems valid to me, and it covers a lot more than just two use cases.

I don't think I have voting rights, but I'm in favour of :

(d) Commit unlocks nothing, but warns if there are still locks in
force. Commit --unlock unlocks everything
     Revert unlocks nothing, but warns if there are still locks in
force. Revert --unlock unlocks everything

Thus if I have (svn status output)
M K x.c (modified and locked)
   K y.c (unmodified and locked)

svn commit : commits change to x.c only(svn st = K x.c, K y.c)
svn commit --unlock x.c : commits and unlocks x.c only (svn st = K y.c)
svn commit --unlock : commits x.c and unlocks x.c and y.c (svn st = )

.. and exactly the same if you s/commit/revert/g to the above.

As a separate-but-related item
 (e) new command "svn cu" as a shortcut

- Walter

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 23 00:56:45 2005

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.