On Wed, Mar 30, 2022 at 9:02 AM Julian Foad <julianf...@apache.org> wrote: > > Karl Fogel wrote: > > I think printing these messages to stderr makes the most sense. > > There are plenty of programs out there that parse the stdout of > > 'svn'; we don't want to interfere with them. > > > > As you point out, it's especially important for 'svn diff' and > > 'svn cat' that stdout remain untainted. Therefore, we can either > > always print these messages to stderr (across all commands), or > > not print them for 'svn diff' and 'svn cat' (but that would be an > > odd inconsistency). > > > >> Anybody want to recommend what we should do for 'cat' and 'diff'? > > > > As per above: I think we should print the messages to stderr for > > everything, including those two. > > Printing progress notifications for data-output commands (diff, cat) to > stderr does however invite bikeshedding. Currently in our test suite we > assume any stderr output (from diff, cat) should be flagged as a test > failure. We can change that, but it indicates that some users may > consider it a failure too. We would need to agree and decide whether > that's going to be unconditional or if the user needs to be able to turn > it off for convenience and for backward compatibility.
This is off-topic but somewhat related. As I have been building my process for doing the release I am running the build and tests in background with stdout and stderr captured to different files. It is interesting to see what goes where. For example, for some reason the Python bindings test results all go to stderr when every other test goes to stdout. That took me a bit to figure out as I thought the tests were not running for some reason as I reviewed the log of the process. There are also a lot of warnings emitted as we build our code, especially in the bindings. Mark
