random thought of the day - a progress bar for tree transforms ?

[John A Meinel]

Aaron Bentley wrote:
> John A Meinel wrote:
>>> Aaron Bentley wrote:
>>>
>>>> Robert Collins wrote:
>>>> | Aaron,
>>>> |     you may have done this already, but what do you think of the idea of
>>>> | tree transform operations accepting a progress bar?
>>>>
>>>> Yeah, we could do that.  Off the top of my head, there are four phases:
>>>> 1. transform creation (calculating the build, revert or merge operation)
>>>> 2. resolution of filesystem conflicts (this may run 1 to 10 times)
>>>> 3. application of removals (renames, deletions, unversioning)
>>>> 4. application of insertions (renames, creations, versioning)
>>>>
>>>> I suspect that your average transform spends most of its time in 2.
>>>>
>>>> Aaron
>>>
>>> How do you get '1-10' times?
> 
> Conflict resolution may introduce new conflicts.  Rather than try to
> predict all the possible interactions, I thought it would be more robust
> to just run the resolver several times.  10 seemed like a good number.
> 
>>> It just realizes that it could conflict
>>> that many times? Or are you just saying "this could run repeatedly".
> 
> 10 is the maximum.
> 
>>> It would be really nice to have transform have a progress bar, since in
>>> a pull you tend to get a progress, and then all goes silent for quite
>>> some time.
> 
> Okay, I can do that, but I'll do it in a separate branch, so it doesn't
> interfere with getting Transform merged.
> 
>>> I'm thinking that if it is a fixed number of iterations, just do the
>>> progress as 14 steps, and skip ones you don't use.
>>> But it might be nicer to have an idea how many files you are checking,
>>> and iterate over that instead.
> 
> On the plus side, we all seem to agree that nested progress bars would
> be nice.  On the minus side, no one's actually done it yet...

I did it for a different project. But the model is a little bit
different. (You have a Progress object, which you can call new_prog =
prog.sub_progress(count, message), to instantiate a new one).

I'm not sure how the model would interact with the bzr progress model.
And I don't really feel like changing all of the code. :)

I can certainly give the layout algorithms, which work pretty well
considering we just have a text output.

Have we considered going to curses since that is built into python? Then
we could do all kinds of fancy stuff. :)

> 
>>> (That, and we need to figure out why branch doesn't do anything for
>>> quite some time, it doesn't seem to be CPU or bandwidth bound during
>>> that time, probably latency bound).
> 
> I dunno.  For merge, I'd have a guess, but not for branch.
> 
> Aaron

I have your TTransform email marked to be reviewed. I'll try and get it
done now.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060214/bfc8270a/attachment.pgp