[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-03-18 17:16:24 CET

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?

'svn revert' is a command whose definition is "permanently destroy
data". 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.

> Benefit:
> - revert behaves like the rest (implicit target, recursive by default)
> - therefore doesn't annoy the user
> - prevents data loss a lot better
>
> Please share your thoughts.
>

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 18 17:19:29 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.