>> 3. Finished working and move on to something else
>
Sorry yes meant (a) (commit and unlock all)
> 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",
It's not, and I don't seriously suggest a command "commit-and-unlock".
But I never type "svn commit" either, I type "svn ci". Maybe a shortcut
"cu" would work without a "long form". I don't know. Maybe if the
switch has a short form then "svn ci -U" is no problem: I aften add a
-m "message" anyway, if the log message is short enough.
> 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.
>
I had in mind something like this:
C:\work\www\docs>svn ci -m "Website: updated docs"
Adding (bin) Web site design overview.odt
Sending Xaraya Configuration.odt
Transmitting file data ..
Committed revision 5.
Warning: 2 files remain locked
C:\work\www\docs>
On the Fatal/Error/Warning/Info/Debug scale this is "Info" I guess. same
effect, it is just bringing the remaining locks to my attention.
Alternatively of course
C:\work\www\docs>svn ci -m "Website: updated docs"
Some files in scope are locked, specify --unlock or --keep-locked
and try again
C:\work\www\docs>
I'd personally prefer the first option, but if there isn't clear
consensus on what the default commit behaviour should be maybe the best
thing *is* not to have a default. People with no locked files won't be
inconvenienced either way.
Of course, GUIs can do what they damn well please. Most surely display
the equivalent of svn status anyway, and I'd be surprised if they didn't
incorporate a [ ]Keep locked checkbox on at least the whole commit if
not on a per-file basis.
- 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 02:20:49 2005