Karl Palsson <kpalsson@cisco.com> writes:
> Yeah, I would, disk space is cheap. I wasn't proposing making it the
> default however. If you don't approve, that's fine with me, but all
> you have to do right now is leave out the diff > mypatch, and it's
> alllll gone. The 'Protection' afforded by requiring a parameter to
> revert is effectively useless in my mind. You very quickly get to the
> point where the . is automatic, just like ./blah to execute stuff.
I don't follow your train of thought.
The maxim "don't lose any user data" is indeed one we live by, but we
apply the maxim to situations where the data might be lost *without*
the user expecting it to happen. For example:
* when receiving a conflicting update, create all three fulltexts
* don't allow the deletion of something that's out-of-date
* don't ever overwrite an unversioned file
But is this situation, you're objecting to the safety of a command
who's *purpose* in life is to toss changes! It's like objecting to
the unix 'rm' command -- "but doctor, it might delete data!" -- "then
don't do that."
The svn commandline client is like any unix program -- flexible enough
to let you do cool things, but then also a tiny bit dangerous if used
carelsessly. An educated svn user should understand that 'svn
revert', just like unix 'rm', should be handled with care. If this is
too unfriendly, then that's why we have GUIs. (I imagine a GUI,
could, for example, back up the edited files into a 'trashcan' before
running svn_client_revert(). Changesets could then be resurrected
from the trash.)
But my point is: 'svn revert' exists to destroy local changes, not to
back them up. If users want to back them up (with 'svn diff') before
destroying them, they're certainly free to do so. And I think the
book could certainly address this point.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Aug 10 00:29:46 2003