non-recursive status of a directory?

[Mark Hammond]

> So... how are you going to handle files which have been removed? It is
> a general
> weakness of Tortiose, as you can't pretend that there is a file there.

I'm not quite with you here.  If I ask bzr for the non-recursive status of a directory, won't that include missing files from that directory?  Missing files in child directories isn't relevant when looking at the parent - just like "modified" files in the child directory, they will be handled by a recursive filesystem crawler.

> And how do you indicate to the user that there is something that needs
> committing?

I fear we are talking at cross-purposes as I don't think I understand what you are asking here either.  There is a state shown when something is modified - that state implies it needs committing.

> Specifically, I think you need to modify the overlay on the containing
> directory. Even if this isn't fully recursive. Otherwise when a file is
> deleted/removed, nothing changes except it is hidden.

Right - yes, we do notify the *containing* directories when a file is detected as missing or modified.  It will work something like this:

* Request comes in for status of directory "foo"

* Status of files is returned, and non-recursive status of subdir 'bar' returned.

* Sub-dir 'bar' has a 'temporary' state of non-modified, and dir is queued for crawling.

* Windows exlporer shows icon indicating directory 'bar' is unchanged.

* Directory crawler queue gets to 'bar' - it does the same as above - non-recursive status, and all child directories are queued for crawling.

* Eventually, directory crawler finishes a directory (ie, it has no sub-directories).  The status of that directory is now known.  Tortoise sends a "shell notification", forcing Explorer to re-ask for the status - it now gets "modified".

* *All* parents of that child directory are similarly notified - their state is now known as "modified" (unless it already has a "more important' status than modified), and a change notification is sent for that folder.  Ditto to the very root of the disk.

So the key points are:

* If a folder status isn't in the cache, it is initially returned as 'unmodified'
* We crawl the directory, magically telling explorer when we have determined the *real* state at each level.
* Parent directories do "inherit" the state of their children - its just that BZR never has to itself recurse for this to happen.

Is that any clearer? 

Thanks,

Mark