Lee Burgess wrote:
> >
> > Anytime I have to carefully grub through pages of output, most of
> > which is just "business as usual", I think the interface is borken.
That is why I prefer to implement "verbose" as a leveled option.
0 -> don't print anything at all, period.
?? -> print out information about every tiny step, so a user can
figure out a problem
In between, whatever makes sense for the application.
I like user entertainment, you do not. Stop, we're both right ;-).
> That being said, I totally agree with what Jim is saying at the same
> time. I too have been bitten when I do an update and missed the
> conflicts because they scrolled way the hell up in my shell buffer.
In this context, it would make sense that a conflict would
cause a non-zero exit code. If you were letting the output
be verbose and you were not capturing the output, you would
know there was a problem, at least.
> > Here are two possible solutions that occurred to me:
Silencing all but crucial messages should be a user's choice.
It must be made available. The other is a worthwhile idea.
"divert" high-priority messages to a temporary file, and
re-emit them at the end. Sounds like a message dispatch routine
is appropriate that understands the priority of each message.
AKA: ``cmn_err()''??
> - SVN will always report things that need attention, like conflicts.
> These things will always be the last thing returned by the client to
> guarantee the user sees it. The user has the option of turning on
> or off all other messages....
The user has the option to turn everything off, *even* these messages.
``--verbose=silent'' should be equivalent to redirecting stdout and
stderr to /dev/null. :-) You get what you ask for.
Received on Sat Oct 21 14:36:12 2006