Bruce Korb <bkorb@sco.COM> writes:
> 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.
A conflict is not an error in the sense of something wrong in the
execution environment, or something unfixably wrong with the data or
with Subversion.
Considering that Subversion continues to "know" where there are
conflicts after the update is done, and can optionally notify the user
of the conflicts at the time the update is run too, adding a non-zero
exit code seems like overkill.
Let's save it for true error conditions, such as a corrupt working
copy, unreadable files, etc.
> 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()''??
[Side note: why are we caring about the implementation? Diverting
msgs to a tmp file is one way, but svn can just save up the msgs
internally and re-emit them at the end of the command, too. Then
there's no danger of the tmp file being left around.
Whichever... Let's talk about how we want the interface to look and
behave, *then* talk about how to achieve it.]
> > - 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.
Agree.
Received on Sat Oct 21 14:36:12 2006