[bug] Repository.copy() copies inventory first

[Robey Pointer]

On 16 Feb 2006, at 20:22, Robert Collins wrote:

> On Thu, 2006-02-16 at 22:14 -0600, John A Meinel wrote:
>> Robert Collins wrote:
>>> On Thu, 2006-02-16 at 20:01 -0600, John A Meinel wrote:
>>
>>
>> ...
>>
>>>> I wasn't planning on passing the inventory copy, because it is only
>>>> copying a single file ('inventory.weave').
>>>> Instead I figured it was better to give a specialized update  
>>>> which made
>>>> it clear what was being copied.
>>>
>>> Seems to me that transports like SFTP can provide
>>> [========           ] 'copy inventory' 150/400
>>>
>>> indicators. Inventory.weave tends to get very big, and I'd  
>>> expect  some
>>> ui feedback during that to be nice.
>>
>> That would be wonderful. But the information just isn't available.
>> 'copy_multi' code only knows that it is copying a list of ids, it
>> doesn't know how big any of them are. And SFTP doesn't know to put a
>> progress in the case that something is bigger than X bytes.
>
> But the sftp transport *can* do it if it chooses to. If we dont  
> make the
> pb available, then it can't. There is a bit of a confusion in the pb
> management, I think 'ui_factory.progress_bar()' should know how to
> nest/stack/whatever the progress bars (whether thats one instance  
> or not
> the client does not need to know. That implies we should have a
> 'progress_bar.finished()' or ui_factory.return_progress_bar() api too.

Yeah, my new ProgressBar has push()/pop() methods to add/remove new  
child progress bars, so you should be able to pass a single object  
around and get the right behavior.

I've been waiting for bzr.dev to catch up before trying to make a  
pbar-replacing patch.  Sounds like maybe that will be a while? :)   
Should I try against another branch, like one of the integration  
branches from you or John?

[One nice thing we could do then would be global debouncing.   
Transports could ask for a new progress bar for each transfer, but if  
it takes less than <time>, nothing would ever be displayed.]

robey