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