'bzr status' stats each file multiple times

[Robey Pointer]

On 4 Dec 2005, at 11:41, John A Meinel wrote:

> Michael Ellerman wrote:
>> On Sun, 4 Dec 2005 08:43, John A Meinel wrote:
>>
>>> I think we should have a timeout value. So that if I stat'd the file
>>> within the last X seconds, I assume the file hasn't changed.
>>> We can even go one better, and do a double check saying, If the  
>>> files
>>> mtime is older than Y seconds, and I have stat'd the file within X
>>> seconds, don't stat again.
>>
>> Hmm, that sounds like a kludge to me - I think we can improve on  
>> the current
>> times before we need to resort to something like that.
>
> How is it a kludge? Isn't it exactly what you just requested. Stat
> everything 1 time?
> It is actually a slight benefit on top of it, which says that you can
> respect that something might change while you're working, so you will
> expire entries after a while.
>
> It might be fancier than is really needed. We could certainly just  
> cache
> all of the stat entries.
>
> What if you simplify it to say, "If I have statted this file within  
> the
> last 5 seconds, don't stat it again".
>
> Though I'm still tempted to say, "If I've statted the file within the
> last 5 seconds, and it more than 5 seconds old, don't stat it again"

Speaking only for myself, I would be 100% content if it just statted  
each file once, period -- making it a snapshot of your tree as it  
existed at some point after you hit [Enter] on the bzr command.

I think it's reasonable to say: If you change files in the tree while  
bzr is running, the command results may be stale.

Trying to heuristically determine if files are changing during the  
operation, and trying to stay manicly up to date by re-statting,  
seems like way overkill. :)

robey