I apologize; I haven't time/energy to refute this. Maybe folks on the
dev@ list will find your arguments persuasive, you might want to repost
there.
On Mar 18, 2005, at 11:12 AM, Markus Bertheau ☭ wrote:
> В Птн, 18/03/2005 в 10:16 -0600, Ben Collins-Sussman пишет:
>> On Mar 18, 2005, at 10:05 AM, Markus Bertheau ☭ wrote:
>>
>>> In particular it is not recursive and you need to tell it the target
>>> to
>>> operate on explicitly. Everyone knows this.
>>>
>>> This behaviour is a workaround for the fact, that users, who by
>>> mistake
>>> revert, lose their local modifications. The thinking goes like this:
>>> If
>>> I annoy the user with the unexpected behaviour of svn revert, he'll
>>> think twice about it and won't issue reverts by mistake.
>>>
>>> A real solution to this problem that does not involve annoying the
>>> user
>>> is as follows:
>>>
>>> Upon revert, store the local modifications in a hidden file. Offer a
>>> command "unrevert" (or similar), to restore the local modifications.
>>>
>>
>> I don't follow this logic. Where do we stop the commands? Should we
>> create an 'svn ununrevert' command too?
>
> No. Upon unrevert, try to merge and if neccessary report a conflict. I
> don't see a possible need for an ununrevert.
>
> Unrevert is probably not the best choice of words, but that doesn't
> hinder the argument.
>
>> 'svn revert' is a command whose definition is "permanently destroy
>> data".
>
> I thought it's definition was "revert my local working copy to the
> repository version". Users surely like software with a command
> "permanently destroy my work" less than software that 1. doesn't annoy
> them by not doing what they expect 2. let's them correct their
> mistakes.
>
>> Not "make a backup of data". Having it create a backup makes
>> as little sense to me as teaching the unix 'rm' command to make
>> backups.
>
> The equivalent of unix rm is svn rm. And after all, svn rm can be
> undone. (modulo the --force thing, to which a similar argument probably
> applies.) I don't see a problem changing the definition of revert to
> "revert my local working copy to the repository version and let me undo
> that in case I later regret to have reverted".
>
>> If anything, I think an alternate way of solving the annoyance would
>> be
>> to make 'svn revert' prompt the user for confirmation that he/she
>> really wants to destroy data permanently. It would be similar to the
>> way that 'rm' is aliased to 'rm -i' by default on many unix-y systems.
>
> That just exchanges one annoyance for another and doesn't help the
> issue
> at all. I see four cases:
>
> The user does (1) / does not (2) revert often.
> The user wants to revert (but in 5% of the cases he later regrets and
> wants the data back) (A) or accidentally issued the revert command (B).
>
> In case 1A the user will already be accustomed to the fact that
> reverting requires him to confirm his intention, which he will do
> automatically, almost subconsciously. He later regrets the revert, but
> the data is gone.
>
> In case 2A the user is confused and interrupted in his work flow
> because
> the command didn't do what he want; it behaves differently from the
> rest
> of the svn commands. After getting over this, he reads the
> confirmation,
> and because he really wants to revert, he confirms. He later regrets
> the
> revert, but the data is gone.
>
> In case 1B there are two possibilities, and it is not clear to me,
> which
> one will happen more often.
> - One is that the brain of user learned that when a svn command wants
> confirmation, he always gives it. This is based on the fact that in 95%
> of the cases reverting was what he wants and he didn't regret it. But
> we
> talk about the other 5% here, so he regrets the revert later, but the
> data is gone.
> - The other possibility is that the user's brain learned that when he
> wants to revert, there's a confirmation to confirm. Because he does not
> want to revert, he does not confirm. The data is saved.
> I do think the first case is more likely to take place.
>
> In case 2B the course of events depends on the exact way the user
> accidentally issued the revert command. The confirmation will probably
> save him. The data is probably saved.
>
> With svn unrevert the situation looks like this:
>
> 1A: The user's brain did not have to learn that some svn commands
> requice confirmation. When the user regrets the revert, he unreverts
> it.
> The data is saved.
>
> 2A: The user's workflow is not interrupted. The command behaves like he
> has gotten accustomed to from the other svn commands. He confirms the
> revert, later regrets it, (maybe asks on the mailing list how to
> unrevert, someone answers "just use svn unrevert"), and unreverts. The
> data is saved.
>
> 1B: The user's brain did not have to learn that some svn commands
> requice confirmation. The user regrets the revert and unreverts it. The
> data is saved.
>
> 2B: The user later regrets the revert and unreverts it. The data is
> saved.
>
> Conclusion: svn unrevert offers a better user experience that the svn
> revert confirmation or the current behaviour. It also handles the
> user's
> data more respectfully and responsibly.
>
> Please tell me about any crucial flaws in this argumentation.
>
> Thanks
>
> --
> Markus Bertheau ☭ <twanger@bluetwanger.de>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 18 18:21:29 2005