Walter Nicholls wrote:
> 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.
Brian was specifically asking for the "default" behaviour, but that was on the
assumption that the single command "commit" was used, whereas you are proposing
two separate commands, so that question is moot.
> 3. Finished working and move on to something else
> This is (b)
Given what you said above, I assume you mean "This is (a)" here.
> Is there a problem with EITHER
> - adding a new command (commit-and-unlock)
There's no technical difficulty, just the significant "social" implications of
increasing the command set. Why is "svn commit-and-unlock" better than the
proposed "svn commit --unlock", other than that it avoids the question of which
is the default? Is avoiding the need for a default useful? Maybe it is.
> OR forcing the user to specify if SVN COMMIT detects that locks are
> present (in scope)?
Now, that is quite a reasonable fourth option: "commit" fails if any targets
are locked and neither "--unlock" nor "--keep-locks" was given.
> 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).
OK, that's an argument in favour of (c).
> 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
If "commit" unlocks nothing, then it is perfectly normal for there still to be
locks. It is silly to issue warnings for perfectly normal situations. Perhaps
you mean, or perhaps it would be reasonable to require that the progress output
must indicate where locks are present.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 23 01:44:42 2005