On 24 Mar 2022, Julian Foad wrote:
For 'svn diff' especially, if we don't print the notifications,
then we
miss out on informing the user during one of the times when it
could be
particularly valuable to them. (They are waiting for diff output,
which
previously in svn used to come quickly.)
It would be ugly to print these notifications in the stdout
stream.
Diff output format rules do allow it to contain new informative
lines
outside the diff hunks, but this kind of notification would not
be
useful or nice for consumers of the diff.
Print progress notifications to stderr? That is what some other
command-line tools do. Some even have command-line flags to
control
where it is sent. One precedent we have is warnings, e.g. in "svn
proplist nonexistent-target valid-target" a warning about
'nonexistent-target' goes to stderr while the primary output for
'valid-target' goes to stdout. I am not sure how I feel about
printing
them to stderr. I could be persuaded either way (print them to
stderr or
not at all).
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.
This is only a concern for command-line clients. GUIs have other
ways to
separate the progress notifications from the primary
output. Therefore
this is all a question of what to do in the client layer, the
'svn'
executable; the library will continue to call the notification
call-back
if the client supplies one.
Understood (and thanks for making it clear & explicit).
Best regards,
-Karl
