'bzr status' stats each file multiple times

[John A Meinel]

Michael Ellerman wrote:
> On Sun, 4 Dec 2005 14:24, John A Meinel wrote:

...

> 
> No I wasn't suggesting compare_trees() cache anything, what I was thinking was 
> that we should change the algorithm so there's exactly one loop in 
> compare_trees() and it just looks at each file as it comes across it - 
> preferably in the optimal order.
> 
> But I think I see what you mean, there's likely to be other parts of the code 
> that cause a stat to occur, even when compare_trees() already has that 
> information.
> 
> I guess I just worry that putting aribtrary "x seconds" timeouts is a bad 
> idea, and might come back and bite us one day.

Another way to do it, would be to have the cache hold the stat forever,
and just expect that the front-end will call "clear_stat_cache" when it
is appropriate.

I think having a second security that it only holds a stat information
for a set number of seconds is more safe. But it might be something that
we start depending on the cache to outdate itself even if we don't want
it to.

So the specifics of having a timeout versus a cache which is cleared
manually, I'm not really picky about.
I would like to get the cache implemented, though.

John
=:->

> 
> cheers
> 


-------------- 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/20051204/c62ea2f0/attachment.pgp