В Птн, 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
Received on Fri Mar 18 18:14:50 2005