[rfc] transport activity locally?

[Martin Pool]

John says in <https://code.edge.launchpad.net/~spiv/bzr/inventory-delta/+merge/8860>

> For local fetches, you don't even get the "transport activity" indicator, so it *really* looks hung. It doesn't even write things into .bzr.log so that you know it is doing anything other than spinning in a while True loop.  I guess you can tell because your disk consumption is going way up...

I don't have a specific proposal so much as a brain dump, so maybe
this is a request-for-inspiration.

As is discussed there, the real fix is probably to give proper
progress from those streaming operations.  However, sometimes we do
spend time in places that don't have an explicit progress bar, and
anyhow seeing the rate is informative.

Turning on transport activity for local disk IO would be fairly
technically trivial.  Possibly for the sake of moving fowards I should
enable it, conditional on a debug flag, while we work out the
following points.  Seeing how much data is read locally might be
interesting to developers.  Perhaps we should optionally log the
totals at the end.

Possibly local IO should just show a "yep, stuff's happening" spinner,
not a specific rate.

Local IO can be pretty fast so we'd want to be sure the cpu overhead is low.

Naively enabling it would tend to give double-counting for
network->local or local->network operations, therefore giving you
twice the data and twice the throughput that is really true, but that
could be fairly easily fixed by showing only the totals for the most
interesting transport, or something else.

As a fix for pb droppings being left on the screen we no longer show
activity except when a pb is explicitly active, on the assumption that
the code will then deal with cleaning it up, which is generally true.
Trying to show it as a "we're doing something" in all cases would only
really work when this
<https://bugs.edge.launchpad.net/bzr/+bug/392435> is fixed.

-- 
Martin <http://launchpad.net/~mbp/>