On Thu, 2002-07-11 at 13:34, Garrett Rooney wrote:
> On Thu, Jul 11, 2002 at 08:24:14AM -0400, mark benedetto king wrote:
>
> > I've noticed that Red Hat, and I presume other modern operating systems,
> > have started, aliasing rm to "rm -i". I suppose the argument is "if you're
> > not knowledgeable enough to unalias rm, you probably need the -i".
[snip]
> > This could be generalized to allow the user-agent to implement --force by
> > always returning "keep going" to these callbacks. If the API is sufficiently
> > rich, the user could choose, for example, "I mean what I say when I 'svn rm',
> > but prompt me for 'svn obliterate'."
I'm not sure these belong in the API, although it does mean that UIs
could share configuration for this. I'd be inclined to suggest a less
specific concept - classification of commands as "safe", "unsafe" and
"dangerous", with three confirmation levels. It's less configuration
data, and more useful if/when new commands are added.
And --force should force things which might break, and as such I'm not
sure the semantics fit svn at all. It would imply that a conflicting
file should be committed, which (I think) should never be allowed.
I think you want a -y/--yes - -f on rm is *not* the same as a lack of
-i, to continue your example, and I often wonder how many new RedHat
users are in the habit of using "rm -f" everywhere when they mean "rm"
without the "-i".
Otherwise I agree.
> if i wanted my computer to ask me 'do you mean it' every time i try to
> do something i'd be running a different operating system.
If I want, or don't want, my computer to ask me if I really mean to do
something, I'll turn it on, or off, respectively.
With a site-administrator hat on, I'd favourably consider defaulting
users to confirmation. I don't really mind how the source distribution
is shipped, personally, but then I can change the relevant parts to suit
my site.
> having a setting one can tweak to make this go away is NOT a valid
> solution. we should have reasonably safe/sane defaults and provide
> tweakable options only as a last resort.
Yes and no.
Yes - the defaults provided must be safe and sane.
No - options and configuration are a perfectly sensible way to ensure
that "irritating" safety can be turned off.
> big -1 on anything that makes the client ask 'are you sure?'. if you
> want that kind of behavior, write a gui client and give it all the
> little confirmation dialogs you want, but keep it out of my CLI.
You already have a confirmation of sorts on "svn revert" - you have to
explicitly type targets whereas usually the '.' is assumed. I'd prefer
it to be a simple question that I could --yes or configure away if I
felt like it.
I entirely understand that you wouldn't want an "Are you sure?"
confirmation - but I don't understand why you don't want anyone else to
have it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 11 17:16:49 2002