> -----Original Message-----
> From: cmpilato@collab.net [mailto:cmpilato@collab.net]
> Sent: Monday, June 09, 2003 7:48 AM
> To: Subversion Developers
> Subject: Re: svn commit: rev 6173 - in trunk: . doc/book doc/book/book
> doc/translations/french doc/user notes
> subversion/bindings/java/javahl/native
> subversion/bindings/java/javahl/src/org/tigris/subversion/javahl
> subversion/bindings/ruby subversion/clients/cmdlin
>
>
> kfogel@tigris.org writes:
>
> > Author: kfogel
> > Date: Sun Jun 8 21:13:41 2003
> > New Revision: 6173
>
> Dude. This really doesn't seem like a change based on a real
> community consensus. Can I ask you to revert -- I mean, undo :-) --
> this change until something more solid is formed?
>
> Perhaps we can explore other options, like making revert prompt you
> first:
>
> $ svn revert -R .
> The operation you are about to perform will throw away any changes
> you've made to the target path(s). Are you sure you want to do
> this? [y/N]
>
> And then add a configuration variable 'revert-no-prompt = no' for a
> sort of "expert mode". Would the list-folk be okay with a solution
> like this?
I like the idea of revert prompting, like rm -i, and have an override, like
rm -f. A user-level operation in a source control system that can
permanently destroy data really should confirm by default, as unlike any
other operation, it's not recoverable.
People are going to occasionally mistype/misthink 'revert' and 'resolve' no
matter what you call them (I've seen people type rm instead of cp by
accident) so changing the names doesn't seem like the right solution (and
the names are perfectly defined as-is). Other than prompting by default,
the other possibility would be to have revert backup files by moving them
out of the way (like foo~, or #foo# or whatever), but that would probably
work better with CVS than subversion due to revert also dealing with
directories.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 10 02:16:36 2003