[RFC] revert commit progress output?

[Robert Collins]

On Thu, 2007-06-28 at 10:53 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I don't find the commit progress output changes to be an improvement.  I
> could eyeball the old progress output.  I have to read this version.

OK, thats an interesting point and one to take into consideration with
our UI...

> I know there were flaws in the old progress bars, but I don't think the
> problem was the bar.  It was the other things the output said.

I think the bar had two major problems:
 - it presumes that we can estimate 'progress' in a meaningful way. I
don't think we can.
 - it reached 98% complete nearly instantly then would essentially hang.

> So I propose reverting commit progress output to the old format.  We
> don't have to get rid of progress bars to improve our progress
> indications.

I don't object to having a progress bar - what I think we need to cover
though are:
 - tree size is essentially unknown with the apis we are working
towards. The fact its known today is arguably an unreasonable constraint
on the underlying api. e.g. a split-inventory, however that is done,
will only be able to say 'the top node contains X entries' - so as we
walk we will see information (in the code, not UI I mean):
processed X entries, know the existence of Y (>X) entries, have Z nodes
which are unconstrained in size and may contain many times the currently
known entries.

Shown as a progress bar this gives a bar that shrinks as the total (Y)
increases which occurs as Z is processed. Exposing the nature of the
data more - e.g. "Processed X entries, Not yet examined Z+Y-X entries" -
removes this congitive dissonance of seeing a progressbar that goes
backwards.

What about showing progress as an estimate of time? We do know that we
have a number of different top level things - stages - during commit,
but we don't know the relative time of these things. For instance, given
two lightweight checkouts one may spend much more time inserting data
into the repository than the other due to networking overhead. Detecting
changes when there is a maybe-modified iso may be much slower than it
usually is and you can get detection taking 10 seconds and insertion of
data 0.1 seconds. So we can't pre-judge what ratio of time should be
allocated to each stage. And that means a sliding bar is not going to
reflect the actual fraction of the total time needed, *nor* the amount
of total work needed because time and work are tightly coupled. 

When we have something that has a predictable number of steps which have
a low variation of time per step then I think progress bars work very
well.

I think your point about 'at a glance' is very good though, and I agree
ian's changed UI loses that. So I'd welcome some way to get that back
without losing the (to my mind) significantly increased clarity that the
current output has. 

-Rob


-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070629/e33396f7/attachment.pgp