C. Michael Pilato wrote:
>"Brian W. Fitzpatrick" <firstname.lastname@example.org> 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
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Feb 23 00:56:45 2005