[RFC] Clean up progress bars during fetch

John Arbash Meinel john at arbash-meinel.com
Sat Nov 4 17:57:06 GMT 2006


After having it brought up a few times on IRC this week, and Matthew
Fuller putting together his "UI Warts" page, I got motivated to take a
little personal time this weekend and clean up the progress indicators
during fetch.

The attached bundle carries a few changes with it, but the overall
effect is that doing 'bzr branch sftp://host/foo' now gives a much more
meaningful update about what is going on. The branch is available here:
http://bzr.arbash-meinel.com/branches/bzr/0.13-working/fix_fetch_progress

This isn't quite ready to merge, because I broke a few of the Progress
tests, and I really should add a test for the change to ProgressPhase.
But in the short term, it *really* makes the 'bzr branch' progress
meaniningful. The basic changes are:

 2121 John Arbash Meinel        2006-11-03
      Use time.time() because time.clock() is CPU time, not wall time

^- I already have a merge request for this, but it wasn't worth doing
the rest without it.


 2122 John Arbash Meinel        2006-11-04
      Change progress logic for fetching.
      Allow ProgressPhase to update its message
      Split up RepoFetcher.ProgressPhase so that it can be used inside
      called functions this lets us update the progress at appropriate
      times.

^- This mostly lets me split up the phases to be meaningful as progress
goes forward.


 2123 John Arbash Meinel        2006-11-04
      Get rid of the startup throttling

^v- The only reason we really have it is for Knit Index, because it was
thrashing. And since I've seen creating progress bars in
KnitIndex.__init__ start showing pretty heavy in the 'bzr branch'
profile, I figure we should clean up all of that stuff.


 2124 John Arbash Meinel        2006-11-04
      Get rid of progress bar during KnitIndex creation
      make sure 'bzrlib.ui' is actually imported before using it
      get rid of nested progress bar during Knit.join(). It should never
      be so slow that we need it, especially a per-line update.
      KnitIndex creation should have a progress at a higher level,
      not inside the __init__.py function.

 2125 John Arbash Meinel        2006-11-04
      Add nice printing functions for debugging Progress classes

^- this helped me debug this -v

 2126 John Arbash Meinel        2006-11-04
      Fix bug in Knit.iter_lines_added_or_present_in_versions which was
re-using a variable


TODO:
  The biggest thing that needs to be done at this point is to change the
  HTTP.readv() implementation. Right now it doesn a big download, then
  breaks up the file and yields the data. What we really need is for it
  to yield the data as it is read. sftp and local transports do this,
  and it means that we can get a meaningful progress while we are
  downloading inventory.knit to find what file ids are involved. If you
  want to see the difference use a machine that you have access over
  sftp and http, and you can see how the phase 1/6 over sftp has a nice
  updating progress, and over http it just hangs while it downloads all
  the data.

It would be really nice to have people play with this, and let me know
if they think it is better than what we used to do. If people like it,
then I'll spend the time to fix up any broken tests, and get it merged.
(*I* like it, so I will probably do it anyway, but feedback always helps)

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_fetch_progress.patch
Type: text/x-patch
Size: 64542 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20061104/9caa4a51/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20061104/9caa4a51/attachment.pgp 


More information about the bazaar mailing list