On Mar 18, 2005, at 11: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.
>
> 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.
I don't like the idea of a recursive revert being the default
operation. The recursive/non-recursive nature of commands is a known
inconsistency at least. Revert also can be made recursive with the -R
or --recursive switch, so I guess I just don't find it annoying enough
to take the risks associated with changing the default.
Saving the local changes could get complicated. Save them for how
long? Until committing I supposed, but what if you make new local
changes before attempting to 'un-revert' ?
Scott
---------------------------------------------------------------------
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:22:05 2005