Den tors 24 mars 2022 kl 11:34 skrev Julian Foad <julianf...@apache.org>:
> 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. > I didn't think of these command before but I agree it might be confusing to have these notifications in the middle of the actual data stream. Good catch! > 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). > stderr sounds good to me, but I'm maybe not the best judge. At least there is a possibility for the user to separate the different streams. > Anybody want to recommend what we should do for 'cat' and 'diff'? > > For the time being I am going to make 'svn' suppress hydrating > notifications for 'cat' and 'diff'. We will at least get the benefit for > the other subcommands. > How does svn cat handle any other informative or warning messages? 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. > +1 /Daniel
