non-recursive status of a directory?

[Mark Hammond]

Tom writes:
> It seems to me that TBZR has an easier job on its hands, since for a
> first pass it really only needs to track branch roots, and not every
> directory.

Yes, that is true.  Indeed, my life would be easier if I didn't recurse need to myself.

I think this really all boils down to one question: if tbzr always asks bzr for the full recursive status of a tree, will that provide a reasonable user experience in the vast majority of cases?

My concern is that we will be facing a fairly "hostile" environment in some cases - think a corporate user who put vista on their 4 year old hardware, then browses from the root of a (slow) network share that holds the latest versions of every corporate repository; think a memory stick that is about to be ripped out without warning.

My experience so far is that on my class of hardware, and for trees the size of bzr itself, it *might* be possible - but I think that is setting the bar too high :)

I'm reluctant to abandon the hard-won experience of TSVN, particularly when it comes to managing thread priorities, detecting when we are "busy" so all status requests should "suspend" for a short while, handling device notifications etc.  I understand that some choices made by TSVN relate directly to SVN, but the examples above don't really fall into that category IMO.

But reluctance doesn't equal refusal :)  If the consensus here is that we should operate assuming a recursive, non-interruptable and non "schedulable" status update, I will go along with that - but I personally would not make that decision :)  Obviously, the later we change our mind, the much harder it is to change.

> Also, only files returned by the status call would need to
> have their states cached - normally a short list. 

Its not the "normally" cases that bother me though.  It’s the "no caches are hot, slow device, poor hardware, impatient user" that I'm thinking about.

... 

> I'd say that it certainly isn't essential to an initial implementation,
> but might be useful to improve responsiveness to file changes in the
> future. (general Windows optimization of BZR would be equally useful
> for that I think).

I'm not that concerned about responsiveness for "real-time" changes that are happening on the file-system (ie, the "watcher") - its more about getting the initial state icons up in the shortest possible (wall) time while browsing in from the root of a tree.

Thanks,

Mark