Shawn Harrison wrote:
> Jani Averbach wrote:
>
>> c) first_file.txt and second_file.txt have been shown on the
>> modified file list, and both of them have been unlocked after
>> the commit (even when content of second_file.txt was unmodified).
>
>
> This is pernicious, and it is Microsoftesque: The program is telling
> me it knows better than I do what I intend.
Oh, I can't resist turning this one right back at you, in two different
ways :-)
* If you intend to commit one file but not the other, then you
should say so on the command line
* SVN is already knows better than you not to commit files with no
textual changes, yet you don't object.
> If I locked a file and didn't work on it, it means I still want it
> locked. What a pain to lock a bunch of files, work on one, commit it,
> and have all my locks undone by so-called smart software.
>
> A plea: One of the things that I love about Subversion is that it
> treats me like I know what I'm doing.
Well, "know what you're doing" is mostly the same as "know how the
software behaves". The difference between SVN's unlocking unchanged
files and "Microsofesque" is that the latter would leave you no
alternative or workaround, whilst you can always tell SVN to commit only
specific files.
> One thing that I haven't seen discussed (I might have missed this) is
> what happens when a locally modified file is unlocked: If there are
> local changes, it would seem that the file should be committed before
> it is unlocked. So in that case I would expect "svn unlock target" to
> fail with a warning, unless I use --force.
I agree with this part: allow a "svn unlock" only if the target isn't
modified, unless with --force. Usually you'd want to "svn revert" the
local changes anyway, and revert will remove the lock. Or will it?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 17 02:49:53 2004