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

[Aaron Bentley]

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

Jari Aalto+mail.emacs wrote:
> * Thu 2006-06-15 Aaron Bentley <aaron.bentley AT utoronto.ca>
> * Message-Id: 4491BCBC.5040808 AT utoronto.ca
> 
>>Progress bars were a response to a real problem: People would run a bzr
>>command, and nothing would happen that they could see.  How long would
>>it take?  They had no idea.  Was it stuck?  No idea.  I've been there,
>>and I don't want to go back.
> 
> 
> I welcome all the hard work put and the progress bar is nice in
> situations where it fits. I assume many pof the developers here use
> remote connections to exchange data in bzr project etc.
> 
> But, remember that there is crowd out there, who do not participate on
> projects / need remote projects, where this progress bar may be nice.
> The mass uses VCS tool to manage local things, even in companies.

The progress bar is not only for remote operations, but also for slow
local ones.  I originally wrote it for 'annotate', which was a slow
local operation at the time.

> The current problems:
> 
> - Check in's for small files is fast ("flickers", no need for progress bar)

Everyone agrees that should be fixed.

> - It breaks pipes and sane error handling ("grepping results")

It works quite nicely with pipes for me.  When I run bzr log|less, for
example, the progress goes to stderr, so it's displayed immediately, and
the log messages go to less.  The same would be true for grep.

> - It doesn't work on slow modem connections ("takes bandwidth")

This is unfortunate, but I don't think it's a common case.  We can
provide an override, for this case, though.

I think it is common for modem-related software like BBSes to indicate
progress, though I suppose dot-based progress is used more often.

> - It doesn't work on internal shells ("Emacs: M-x shell")

Are there examples other than Emacs?

As I recall, the problem is that Emacs terminal emulation is really,
really weak.  My memory is that showing a series of dots was a very
expensive operation.

> - It is not good for 3rd party programs that build in top of "bzr"
>   (in programs using pipes or Emacs modes that use "process launches")

This isn't an argument for changing the default, because programs that
are built on top of bzr can supply their own options.  (And probably
should-- starting with --no-plugins and --no-aliases.)

> The benefits:
> 
> - On remote connections the progress is shown
> - On big files the progress is shown
> 
> It really, really should not be on by default.

I understand that you feel this strongly, but I disagree.

> I understand that tool should be ready to use as it is installed, but
> I believe the progress bar is more "convenience feature" than a
> necessity and therefore it should be "extra" and "tunred on on
> depand".

I think you're underestimating the necessity for people to know that
something is happening when they perform a long-running command.

I'm much more inclined to make the feature work properly than to give up
on it and turn it off by default.

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

iD8DBQFEkc5r0F+nu1YWqI0RAmp7AJ43Ic5zbCbOnNXF3FXX9OhNXbX+6wCfTXYs
WieWke/IWnbwhzEJDiQigeE=
=DcUk
-----END PGP SIGNATURE-----