Bug 41734

This is just about percieved performance, not real performance.

To fix that, one would have to add some engine for each command, that
would parse it's output and update the progress bar accordingly. This
is possible (for recursive commands or commands that process more then
one file, it does not have sense for commands processing one file),
but from the implementation point of view this is a time-consuming
task (to do that for all VCS commands). Also, this can make the real
performance only worse.

All pros and cons need to be evaluated, I'm not convinced that this
should be implemented in promotion D.

Sad, pretty sad. Of course that it is all about perception. That's
exactly why we do show splash during startup although it does not make
the start faster. It directly affects usability as the users will
refuse to use product that is not responsive.

Hi,

I am in favor of a real progress bar wherever possible. In my opinion a progress
bar gives the end user the impression that an automated task goes faster, even
if the implementation of the progress bar actually increases the total task
duration up to ±10%. The other progress bar has just the same function as an
hour glass cursor.

If the exact implementation of a specific bar is too resource intensive it is
always better to implement a less exact bar than no bar at all.

For example (just hypothetical):
If you need to check in 100 files and you want a very exact progress bar, you
need to know a lot of things, like file sizes, network performance, and so on to
make an precise indication. But maybe it is also enough to couple it to the
number of files. This may result in a bumpy progress bar, but nevertheless it'll
be better than none at all.

Sincerely,
Patrick Holthuizen