brz 0.8.2 - Disable progress bar and enable it only on -v option

[Jari Aalto+mail.perl]

* Fri 2006-06-16 Matthieu Moy <Matthieu.Moy AT imag.fr>
* Message-Id: vpqu06ld3gl.fsf AT ecrins.imag.fr
> jari.aalto at cante.net (Jari Aalto+mail.perl) writes:
>
> $ foo | bar
>
> you expect "bar" to receive the information it is supposed to process.
> bar doesn't want to see the progress information and informative
> message which are meant for the user.
>
> wget works like this, curl works like this, ...
>
> If, for some reason, "bzr cat" started to show a progress-bar, would
> you expect
>
> $ bzr cat foo.txt -r 4 > foo.old.txt
>
> to give you a progress bar in foo.old.txt ?

Good arguments. You're correct.

>> I understand the need to show progress for non-experienced / win32
>> people that may not have equivalent Unix background.
>
> Does the fact that you have a great unix experience tell you what to
> do when you run
>
> $ bzr some-command
>
> and get no output after 1 minute ?

Yes. find(1) and other commnds work that way (you withe -name "some" which
does not exists where you think it should). 

> If it's not on by default, 90% of people won't bother to learn how to
> activate it, and will complain about bzr beign slow (the fact that you
> see the progress gives a feeling of speed), and opaque.

I don't think this is correct. People are very willing to learn the
tool they are interested in. We shoudl not care about passers by. 

You learn what the ocmmands do, how much time they take when you use
them -- and know what options are best (--verbose, --progresssbar) in
typical cases. Program should not guess that.

Bzr itself is a complex tool; being distributed in design, it is much
more complex than CVS or SVN, so people do have to learn/unlearn lot
of things. It's natural and intuitive to find out that there is
additional features like:

  --progressbar

The are already many --<options>, so this is natural progression of the
learning curve.

Jari