[RFC] Clean up progress bars during fetch

Wouter van Heyst larstiq at larstiq.dyndns.org
Thu Nov 9 21:20:58 GMT 2006


On Thu, Nov 09, 2006 at 12:11:32PM -0600, John Arbash Meinel wrote:
> John Arbash Meinel wrote:
> ...
> 
> > 
> > \ [================  ] Phase 6/6 Copying frizbans ( 10/100)
> > 
> > I kind of like adding 'Phase'. Maybe I should change it so the child
> > update message shows up along with its xx/yyy progress.
> > 
> > I'll play around with that.
> > 
> > John
> > =:->
> 
> 
> I looked into including the child message in the parent progress, and I
> found out why I don't want to do it. Basically, the child doesn't know
> what it is really doing, it has too narrow a world view. For example,
> while we are looking for what file ids have been modified across
> revisions, the child only knows "Walking Content". Which it does for all
> knits. It doesn't know *why* it is "walking content".
> 
> So we still need the meta information to be given from the parent.
> 
> So I did an update which does this:
> - [====               ] Fetching 1/6 Finding involved files ( 905/8236)
> 
> Basically, when a ProgressPhase is created, it sets the overall progress
> indicator, and then as next_phase() is called it updates the second message.
> 
> However, I'm tempted to just always force it to 'Phase 1/6'. I think
> 'Fetching' is actually less helpful than just 'Phase'.
> 
> Thoughts?
> 
> - [====               ] Phase 1/6 Finding involved files ( 905/8236)

As said on irc, I prefer this variant, modulo Matthews concerns about 3
years of tool usage and '1/6' by itself saying enough.

Wouter van Heyst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20061109/fdc9fa2f/attachment.pgp 


More information about the bazaar mailing list