On Thu, Jul 11, 2002 at 09:48:39AM -0400, mark benedetto king wrote:
> On Thu, Jul 11, 2002 at 08:34:51AM -0400, Garrett Rooney wrote:
> >
> > 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.
> >
>
> I know that you run FreeBSD, which probably means you have lots
> of scar tissue in your feet. :-)
*laugh*
> > 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.
> >
>
> I'm okay with the default to be "destroy user data with wild abandon",
> as long as we explain at install time that new users may want to set
> the novice mode.
but we aren't defaulting to 'destroy user data with wild abandon',
we're doing the opposite. we're picking defaults that make it
intentionally difficult to accidentaly destroy user data.
> It is my experience that most systems do default to novice mode, and
> a one-time tweak for experienced users really isn't all that frustruating.
it irritates the hell out of me every time i have to check one of
those 'never show me this dialog again' check boxes, and this is the
same thing.
> > 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.
> >
>
> Well, the thing is, in order to put it in the GUI correctly, the system
> needs to be instrumented to actually call these callbacks.
i'm fine with having any callbacks that are needed, but in this case i
don't think they are.
> We can't expect the GUI designers to know that "svn foo" can occasionally
> be irreversible. Also, even if they *did* know that "svn foo" sometimes
> destroys user data, wouldn't it be nice if they didn't have to prompt
> *every* time, but only when it became an issue?
i don't think it's unreasonable to assume the programmer using our
libraries know these sort of things, as long as we document them.
> I think it would be neat if I could do "svn update --prompt-me"
> and it would say something like:
>
> U foo.c ? (Y/N) Y
> U bar.c ? (Y/N) N
> G foo.c ? (Y/N/E) E
>
>
> Where the "E" option for the merge would bring up $EDITOR with conflict
> markers in place, so that I can hand-merge. I used this sort of feature
> all the time with perforce (p4 resolve -v, IIRC). It rocked. Especially
> because I had files that I knew from experience wouldn't merge well (too
> much very similar code).
>
> You could also have --prompt=G,U. I don't know what the UI should be,
> I'm not a UI expert, but I do know that the functionality would be nice.
> Without a callback system this is really tricky work.
i agree there are situations where you need to ask the user for input
(like we do now for an empty log message from the editor), but i think
it's a subtle line between that and asking too many questions. as
long as we're picking sensible defaults, like requiring them to
specify a directory for a destructive command, then we shouldn't be
questioning what they tell us. the "should we default to . if revert
--recursive is done withtout a target" question should be solved by
looking at the use cases and making a decision weighing safety and
convenience, not by becoming overly chatty with the user.
it's a matter of degree. we should only ask a question if the user
does something really out of the ordinary (an empty log message), not
if they simply run a command (svn revert).
and while i have no problem with some kind of provision for callbacks
to help client writers out, i think 98% if these questions can be
solved at the client level, not at the subversion library level, just
like we do for the log message thing now.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 12 02:27:20 2002