Pristines-on-demand: printing progress notifications

[Julian Foad <ju...@apache.org>]

I thought it would be useful to let users know why Subversion is pausing
for a long time where previously it would not have done. I think if I
were that user, I would want to know. So I tried the attached patch,
printing notifications when it is fetching text-bases.

The result looks like this.

[[[
$ command svn up 1991/*.pdf 1994/
Updating '1991/one.pdf':
DBG: textbase.c:  75: ### open a new session for hydrating
  Hydrating text bases .
  Hydrated 1 text bases
At revision 2231.
Updating '1991/two.pdf':
DBG: textbase.c:  75: ### open a new session for hydrating
  Hydrating text bases .
  Hydrated 1 text bases
At revision 2231.
Updating '1994':
DBG: textbase.c:  75: ### open a new session for hydrating
  Hydrating text bases ....
  Hydrated 4 text bases
At revision 2231.
Summary of updates: [...]
]]]

The "Hydrated N text bases" are redundant: N equals the number of dots
printed in the previous line. This is just for demonstration. So are the
indentations and the DBG lines.

I thought maybe we would like to show this detail by default, and
suppress it when '--quiet' is passed. (Not implemented in this demo patch.)

I was also mildly surprised to see that the fetches are not necessarily
all grouped together at the start of a high-level operation. Clearly
it's doing the 'hydrate' once per explicit target. Actually I remember
seeing this in earlier review, then forgetting as it didn't seem
important. I don't know if we care. I suppose it is unavoidable that a
client's operations might sometimes be grouped like this. Even if the
client library API allows the client to pass all targets in one call, a
client in general may choose to call the library function once per target.

If I were the user, and particularly if I were in a use case where just
one huge file is involved, then I would also like to have feedback on
the (percentage) feedback through the file fetch. It doesn't look like
we have a good way to do that at the moment, but please correct me if
I'm wrong.

Do we like this?

If so, I can clean up the patch a bit and commit it.

- Julian

Re: Pristines-on-demand: printing progress notifications

[Julian Foad <ju...@apache.org>]

The notifications are printed for any command. Let's please pretend I
didn't use 'update' as an example. I don't want us to mix up this
discussion with the discussion about how 'update' shouldn't hydrate.
Let's pretend I used 'diff' or 'revert' as the example, like this:

[[[
$ svn revert -R 1991/*.pdf 1994/
DBG: textbase.c:  75: ### open a new session for hydrating
  Hydrating text bases .
  Hydrated 1 text bases
Reverted '1991/one.pdf'
DBG: textbase.c:  75: ### open a new session for hydrating
  Hydrating text bases .
  Hydrated 1 text bases
Reverted '1991/two.pdf'
DBG: textbase.c:  75: ### open a new session for hydrating
  Hydrating text bases ....
  Hydrated 4 text bases
Reverted '1994/a.pdf'
Reverted '1994/b.pdf'
Reverted '1994/c.pdf'
Reverted '1994/d.pdf'
]]]

Also, in the context of this patch I would remove the 'DBG' debug
prints. We can discuss optimising the opening of RA sessions in another thread.

- Julian

Re: Pristines-on-demand: printing progress notifications

[Julian Foad <ju...@foad.me.uk>]

I made a mistake in:

> 'svn cat' already suppresses these notifications.

CORRECTION:

'svn cat' currently prints these notifications.
'svn diff' currently prints these notifications.
--> TODO: stop printing them here.

It seems the only change needed here is to make both 'svn diff' AND 'svn
cat' suppress those notifications.

Re: Pristines-on-demand: printing progress notifications

[Julian Foad <ju...@foad.me.uk>]

Finished and committed: https://svn.apache.org/r1899173 .

This looks and feels much better to me now.

Example:

$ svn revert -R subversion/
Fetching text bases ..................done
Reverted 'subversion/svn/cat-cmd.c'
Reverted 'subversion/svn/diff-cmd.c'
Reverted [...]

- Julian

Re: Pristines-on-demand: printing progress notifications

[Julian Foad <ju...@apache.org>]

Updated and cleaned-up patch 'hydrating-notifications-2.patch' attached,
for interest. Still TODO: update test expectations.

Re: Pristines-on-demand: printing progress notifications

[Julian Foad <ju...@apache.org>]

Daniel Sahlberg wrote:
> How does svn cat handle any other informative or warning messages?

I don't think 'svn cat' prints any other informative or warning messages.

It occurs to me now that anything on stderr is generally assumed to
indicate an error, in tests in the test suite. We need to update test
expectations anyway (about 30 tests fail when I add the notification to
the other commands); this is just an additional point.

Re: Pristines-on-demand: printing progress notifications

[Daniel Sahlberg <da...@gmail.com>]

Den tors 24 mars 2022 kl 11:34 skrev Julian Foad <ju...@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

Re: Pristines-on-demand: printing progress notifications

[Mark Phippard <ma...@gmail.com>]

On Wed, Mar 30, 2022 at 9:02 AM Julian Foad <ju...@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

Re: Pristines-on-demand: printing progress notifications

[Julian Foad <ju...@apache.org>]

Daniel Shahaf wrote:
> I'm a bit hesitant about disabling notifications _entirely_ in cat-cmd.c
> and diff-cmd.c.  Disabling all notifications (as opposed to only
> hydration-related notifications which we focus on right now) seems like
> it could easily have unintended consequences.  Do we do that elsewhere?

Thanks for the review and discussion.

In "svn" we set the callback to null in a few other places, not many:

  * if (opt_state.quiet)  # all subcommands
  * if (opt_state.xml)  # all subcommands
  * svn propedit  # /* We do our own notifications */
  * svn changelist --quiet  # redundant with "opt_state.quiet"?
  * svn x-shelve/x-unshelve --quiet  # redundant again?

Maybe doing that for "diff" is suppressing too much, as you suggest.

I couldn't previously think of other notifications we might use in
"diff" but now I can imagine things such as "now processing an external
at path X" (now (I haven't checked) or in the future).

It would be best to preserve the possibility of any such notifications
during "diff".

The same applies to "cat", logically, the only difference being a
difference of expectation (we don't expect any other progress
notifications to be printed for "cat" anyway, while for "diff" we might).

Done: in "diff" and "cat", suppress just these particular notifications:

  https://svn.apache.org/r1900110


The rest of my reply (below) is just discussion.

> «diff» isn't unique in having parseable output. [...] I am leaning to
> the opinion that «svn diff» isn't a special case, and «diff» and those
> other commands should all use the same rules for their output.
> [...]
> What are those rules?  Good question.  stdout isn't a good place for the
> hydration notifications, since those are of interest to the (human)
> producer of the output but not to the consumer of the output; [...]
>  
> «svn cat», on the other hand, _is_ unique, in that it's the only command
> whose output format is not controlled by us. [...]

Let me first summarise the logic that led me to the current implementation.
Diff and cat are (presently) the only two data-outputting commands that
may hydrate; the rest are action commands. The output of action commands
is generally feedback to the operator of the command, and adding more
forms of notification to their output is a natural fit.

For the data-outputting commands, I preferred to avoid changing the
output as it would potentially have more consequences on its consumers
than we are willing to deal with. Obviously "cat" is particularly
sensitive, as you point out, and we agree it should print no feedback.

That leaves "diff", which as you point out is categorically similar to
other data outputting commands. A particularity of diff format is it
explicitly allows additional output which parsers should ignore. In that
respect it would be acceptable to add new notifications in its stdout,
even more so than for the other commands whose output we control. But
the issue remains that progress feedback logically belongs to the
operator of the command and not to the consumer of its output (although
the two are often the same). It is reasonably for a consumer of the
output to expect that the output will be repeatable for the same logical
WC state, and will not change depending on the caching state of
Subversion's metadata area. So adding feedback to data-outputting
commands, mixed in with their output, is not a great idea.

Ideally progress feedback would go neither to stdout nor to stderr but
to a third stream. Technically we could implement this easily as an
OS-level stream, but while it's the obvious approach in a GUI, I don't
think the idea of a separate feedback stream is widely used in
command-line environments so it would not be readily understandable and
accessible to users.

Similarly, we could add options to control whether and where such
feedback goes. But at this stage I don't think that added complexity is
warranted, at least not as an add-on handling only this specific case.
Maybe if we were to re-think the command line interface in its entirety,
say as a "2.0" project, that's where it could make sense.

For now it doesn't seem to me that any further changes are needed at
this time, other than the change agreed above to the conditional logic
for the feedback suppression.

- Julian

Re: Pristines-on-demand: printing progress notifications

[Daniel Shahaf <d....@daniel.shahaf.name>]

Karl Fogel wrote on Wed, Mar 30, 2022 at 17:58:55 -0500:
> On 30 Mar 2022, Julian Foad 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.
> > 
> > Because this could be dragged out I'm filing it as a lower priority for
> > now. We can get back to it. (If someone feels able to resolve it,
> > great.)
> 
> Good points, and +1 to prioritizing it lower down relative to shipping the
> main thing!

I'm a bit hesitant about disabling notifications _entirely_ in cat-cmd.c
and diff-cmd.c.  Disabling all notifications (as opposed to only
hydration-related notifications which we focus on right now) seems like
it could easily have unintended consequences.  Do we do that elsewhere?
E.g., in --xml mode?

«diff» isn't unique in having parseable output.  On the contrary, all
our subcommands have parseable output, whether it's "unidiffs" or "seven
columns, then a column of spaces, then filenames" or "XML in <this>
schema" or "RFC822-esque data with localized field names".  Sure, «svn
diff»'s output may be consumed by other tools, but that also goes for
other subcommands (e.g., help/info/ls/proplist/status all have
machine-parseable output even in non-«--xml» mode).  So, I am leaning to
the opinion that «svn diff» isn't a special case, and «diff» and those
other commands should all use the same rules for their output.

What are those rules?  Good question.  stdout isn't a good place for the
hydration notifications, since those are of interest to the (human)
producer of the output but not to the consumer of the output; stderr
isn't a good place, since CLI consumers may interpret that as an error
indication (though the exit code would be zero, EXIT_SUCCESS); and
/dev/null isn't a good place either, since we added those notifications
for a reason.

«svn cat», on the other hand, _is_ unique, in that it's the only command
whose output format is not controlled by us.  That means we can't emit
anything to stdout in «svn cat» without possibly mangling user data.
So, for «svn cat» we don't have the option of emitting notifications to
stdout; we have only the other options discussed above.

Cheers,

Daniel

Re: Pristines-on-demand: printing progress notifications

[Karl Fogel <kf...@red-bean.com>]

On 30 Mar 2022, Julian Foad 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.
>
>Because this could be dragged out I'm filing it as a lower 
>priority for
>now. We can get back to it. (If someone feels able to resolve it, 
>great.)

Good points, and +1 to prioritizing it lower down relative to 
shipping the main thing!

Re: Pristines-on-demand: printing progress notifications

[Julian Foad <ju...@apache.org>]

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.

Because this could be dragged out I'm filing it as a lower priority for
now. We can get back to it. (If someone feels able to resolve it, great.)

- Julian

Re: Pristines-on-demand: printing progress notifications

[Karl Fogel <kf...@red-bean.com>]

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

Re: Pristines-on-demand: printing progress notifications

[Julian Foad <ju...@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.

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).

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.

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.

- Julian

Re: Pristines-on-demand: printing progress notifications

[Daniel Sahlberg <da...@gmail.com>]

Den tors 24 mars 2022 kl 09:53 skrev Julian Foad <ju...@apache.org>:

> Daniel Sahlberg wrote:
> >> I'll put it on my todo list, but I can't promise when I find time to
> >> to that.
>
> I only meant to ask you to clarify what you meant: whether you are
> reporting for TSVN 1.14 or a TSVN 1.15-dev build (based on the
> pristines-on-demand branch or otherwise; I don't know if anyone has made
> any such builds); and whether you meant it was reporting bytes-progress
> specifically on hydrating or just on *some* data transfers.
>

Yeah, sorry. I meant that plain 1.14 on 1.14 WCs is reporting bytes
transferred.

/Daniel

Re: Pristines-on-demand: printing progress notifications

[Julian Foad <ju...@apache.org>]

Daniel Sahlberg wrote:
>> I'll put it on my todo list, but I can't promise when I find time to
>> to that.

I only meant to ask you to clarify what you meant: whether you are
reporting for TSVN 1.14 or a TSVN 1.15-dev build (based on the
pristines-on-demand branch or otherwise; I don't know if anyone has made
any such builds); and whether you meant it was reporting bytes-progress
specifically on hydrating or just on *some* data transfers.

* * * *

About '--quiet' and when to print these notifications (in the
command-line client 'svn').

Commands whose primary purpose is to output data probably should not
display the notifications.

(If they accept flags like '--quiet' or '--verbose', those are for
adjusting their primary information output, not progress notifications.
We historically do not have any debug-level verbosity controls on
commands like 'diff' and 'cat'. I don't think we need to add such
controls before or as part of adding these notifications to the other commands.)

'svn cat' already suppresses these notifications.
'svn diff' currently prints these notifications.
  --> TODO: stop printing them here.

(Those are the only data-output commands that may hydrate.)

The other commands probably should print the notifications by default
and suppress them when '--quiet' is added.

'svn revert --quiet' already suppresses those notifications.
'svn co/up/sw --quiet' already suppresses those notifications.
'svn resolve[d] --quiet' already suppresses those notifications.
Conflict resolver in 'svn merge/up/sw --quiet' already suppresses those notifications.

It seems the only change needed here is to make 'svn diff' suppress
those notifications.

- Julian

Re: Pristines-on-demand: printing progress notifications

[Daniel Sahlberg <da...@gmail.com>]

Den tors 24 mars 2022 kl 09:04 skrev Julian Foad <ju...@apache.org>:

> Daniel, can you confirm if you mean you are using a 1.14-based TSVN, on
> a 1.15 working copy, and it is showing bytes-transferred feedback during
> the hydrating? I had assumed it would need to be rebuilt and modified to
> do that. If that part Just Works already, that's great news.


I'll put it on my todo list, but I can't promise when I find time to to
that.

/Daniel

Re: Pristines-on-demand: printing progress notifications

[Julian Foad <ju...@apache.org>]

Marl Phippard wrote:
> Yes, and I agree --quiet should suppress. [...TSVN] hooked into our
> notifications to be providing an update on bytes transferred. [...] I
> just assumed they would work ... maybe they still do?

Daniel Sahlberg wrote:
>> Yes, I like this very much. The more feedback [...] the less
>> risk/chance of users believing something is wrong. --quiet also seems
>> like a good idea, then powerusers can limit the amount of feedback.

OK, seems I should proceed. Thanks for the comments.

>> I'm primarily using TortoiseSVN and I can confirm that it is
>> displaying the number of bytes trasfered, but I havn't digged through
>> the code to find where these notifications come from.

Daniel, can you confirm if you mean you are using a 1.14-based TSVN, on
a 1.15 working copy, and it is showing bytes-transferred feedback during
the hydrating? I had assumed it would need to be rebuilt and modified to
do that. If that part Just Works already, that's great news.

>> I would want to see the "hydrating" message also in TSVN, but I
>> assume it would not be too difficult to hook into these notifications
>> (if they are indeed a different kind).

Certainly TSVN would need a small update to make it display the new
notifications (hydrating start, hydrating file, hydrating end).

- Julian

Re: Pristines-on-demand: printing progress notifications

[Daniel Sahlberg <da...@gmail.com>]

Den ons 23 mars 2022 kl 23:58 skrev Mark Phippard <ma...@gmail.com>:

> On Wed, Mar 23, 2022 at 5:51 PM Julian Foad <ju...@apache.org> wrote:
>
> > I thought maybe we would like to show this detail by default, and
> > suppress it when '--quiet' is passed. (Not implemented in this demo
> patch.)
> >
> > I was also mildly surprised to see that the fetches are not necessarily
> > all grouped together at the start of a high-level operation. Clearly
> > it's doing the 'hydrate' once per explicit target. Actually I remember
> > seeing this in earlier review, then forgetting as it didn't seem
> > important. I don't know if we care. I suppose it is unavoidable that a
> > client's operations might sometimes be grouped like this. Even if the
> > client library API allows the client to pass all targets in one call, a
> > client in general may choose to call the library function once per
> target.
> >
> > If I were the user, and particularly if I were in a use case where just
> > one huge file is involved, then I would also like to have feedback on
> > the (percentage) feedback through the file fetch. It doesn't look like
> > we have a good way to do that at the moment, but please correct me if
> > I'm wrong.
> >
> > Do we like this?
>

Yes, I like this very much. The more feedback an application provides,
especially with long-running processes, the less risk/chance of users
believing something is wrong. --quiet also seems like a good idea, then
powerusers can limit the amount of feedback.

Yes, and I agree --quiet should suppress. It would be good to
> understand the progress feedback a bit more. I have not used
> TortoiseSVN in a long time but I recall it hooked into our
> notifications to be providing an update on bytes transferred. I think
> they would expect that here too. I realize that is kind of separate
> from adding these notifications and honestly I thought those
> notifications for bytes transferred came from a lower level RA layer
> so I just assumed they would work ... maybe they still do?
>

I'm primarily using TortoiseSVN and I can confirm that it is displaying the
number of bytes trasfered, but I havn't digged through the code to find
where these notifications come from. I would want to see the "hydrating"
message also in TSVN, but I assume it would not be too difficult to hook
into these notifications (if they are indeed a different kind).

Kind regards,
Daniel Sahlberg

Re: Pristines-on-demand: printing progress notifications

[Mark Phippard <ma...@gmail.com>]

On Wed, Mar 23, 2022 at 5:51 PM Julian Foad <ju...@apache.org> wrote:

> I thought maybe we would like to show this detail by default, and
> suppress it when '--quiet' is passed. (Not implemented in this demo patch.)
>
> I was also mildly surprised to see that the fetches are not necessarily
> all grouped together at the start of a high-level operation. Clearly
> it's doing the 'hydrate' once per explicit target. Actually I remember
> seeing this in earlier review, then forgetting as it didn't seem
> important. I don't know if we care. I suppose it is unavoidable that a
> client's operations might sometimes be grouped like this. Even if the
> client library API allows the client to pass all targets in one call, a
> client in general may choose to call the library function once per target.
>
> If I were the user, and particularly if I were in a use case where just
> one huge file is involved, then I would also like to have feedback on
> the (percentage) feedback through the file fetch. It doesn't look like
> we have a good way to do that at the moment, but please correct me if
> I'm wrong.
>
> Do we like this?

Yes, and I agree --quiet should suppress. It would be good to
understand the progress feedback a bit more. I have not used
TortoiseSVN in a long time but I recall it hooked into our
notifications to be providing an update on bytes transferred. I think
they would expect that here too. I realize that is kind of separate
from adding these notifications and honestly I thought those
notifications for bytes transferred came from a lower level RA layer
so I just assumed they would work ... maybe they still do?

Mark