[RFC] revert commit progress output?

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> On Thu, 2007-06-28 at 10:53 -0400, Aaron Bentley wrote:
>> 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.

Even doing it in terms of phases is better than nothing.  People get
used to the rhythm of the phases on their branches.

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

Well, WorkingTree4._iter_changes still knows how big the tree is.  So it
seems possible that it can provide progress info.

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

So if we have a tree like this

   A
  /|\
 B C D

If we've completed B, but not C or D, can't we say we're 33% complete?

It's unfortunate that we have no reason to expect that B has the same
number of grandchildren as C or D, but it's something, and it doesn't
involve going 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. 

Right.
1) we can estimate how long *this* stage takes for *this* tree pretty
accurately, once we've done it a few times
2) people will compensate, and expect certain stages to be faster than
others.
3) we can show divisions between stages on our progress bar

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

The current output goes by too fast for me to know what it says.  So for
me, it's by no means clear.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGhQdz0F+nu1YWqI0RAg2pAJ9AN7o2RIa54VmOjYbQ1FEzziL1BgCfVmzo
m4QEkOj8EUUy6K/5iUkg/hc=
=h1zJ
-----END PGP SIGNATURE-----