Re: Bug: svn revert annoys the user by behaving differently from all other commands

[Markus Bertheau ☭ <tw...@bluetwanger.de>]

В Птн, 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 ☭ <tw...@bluetwanger.de>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Bug: svn revert annoys the user by behaving differently from all other commands

[Patrick Burleson <pb...@gmail.com>]

On Fri, 18 Mar 2005 15:47:20 -0500, Scott Palmer
<sc...@2connected.org> wrote:
> I agree with you except for the argument of it being dangerous for rm
> to be recursive... non-recursion doesn't even make sense in the context
> of rm.  When you rm a file there is nothing to recurse into.  When you
> rm a directory, if successful, implicitly all the children of that
> directory go with it. Basically rm has to by definition always be
> recursive. :)
> 
> Scott

But in it's current state, rm warns you that you are hitting a
directory unless you pass the -r flag. Mostly because from the command
line, without doing a ls -l, you can't tell what's a directory and
what isn't.

This is the behavior of revert. Which I think is important since it
does destroy data.

Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Bug: svn revert annoys the user by behaving differently from all other commands

[Scott Palmer <sc...@2connected.org>]

On Mar 18, 2005, at 12:32 PM, Ronny T. Lampert wrote:

> I'm with Ben and want revert to be as simple as possible.
> If I say "revert", then I want the file be reverted to my checked out 
> version.
> I don't want "revert" to be automatically recursive, because that's 
> dangerous.
> Like making rm per default recurse would be very very dangerous.

I agree with you except for the argument of it being dangerous for rm 
to be recursive... non-recursion doesn't even make sense in the context 
of rm.  When you rm a file there is nothing to recurse into.  When you 
rm a directory, if successful, implicitly all the children of that 
directory go with it. Basically rm has to by definition always be 
recursive. :)

Scott


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Bug: svn revert annoys the user by behaving differently from all other commands

[John Szakmeister <jo...@szakmeister.net>]

Ronny T. Lampert wrote:
[snip]
> 
> 
> I'm with Ben and want revert to be as simple as possible.
> If I say "revert", then I want the file be reverted to my checked out
> version.
> I don't want "revert" to be automatically recursive, because that's
> dangerous.
> Like making rm per default recurse would be very very dangerous.
> 
> Leave revert like it is.
> It is working well.
> And NO - I don't want un-reverts and automatically merges.
> (Please work with large sources - you'll appreciate fast responses to
> you commands and no magic commands that do stuff behind your back. If
> you want to merge, you should do it explicitely.)

I agree that revert behavior should stay the way it is (is it really
that hard to type 'svn revert -R'?).  Besides that, I regularly work
with disk images, and having another 2 GB of data lying around because
of things being saved doesn't appeal to me. :-)

-John

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Bug: svn revert annoys the user by behaving differently from all other commands

["Ronny T. Lampert" <te...@uni.de>]

>>>> 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'm with Ben and want revert to be as simple as possible.
If I say "revert", then I want the file be reverted to my checked out version.
I don't want "revert" to be automatically recursive, because that's dangerous.
Like making rm per default recurse would be very very dangerous.

Leave revert like it is.
It is working well.
And NO - I don't want un-reverts and automatically merges.
(Please work with large sources - you'll appreciate fast responses to you 
commands and no magic commands that do stuff behind your back. If you want 
to merge, you should do it explicitely.)


Cheers,
Ronny

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Bug: svn revert annoys the user by behaving differently from all other commands

[Ben Collins-Sussman <su...@collab.net>]

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 ☭ <tw...@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