non-recursive status of a directory?

[Mark Hammond]

> So if the tradeoff is that: there is a delay proportional to 'bzr st'
> time, then all of the icons appear, I think that would be a reasonable
> tradeoff for the first release.  I think it would only really bite if
> during that delay Explorer was totally unresponsive and from my
> understanding of your documents that's not on the cards.

That would be a change from how TSVN works - it blocks explorer while a
non-recursive status update is performed.  That way the files in a
directory, and in some cases the directories themselves, all get the icon
immediately.  It's the sub-directories that get the special background
treatment to avoid blocking explorer (the explorer "block" times out after
10 seconds, but if that ever gets hit we have a seriously upset user!)

Long term, I don't think we can block for a full status request (consider a
directory with many large branches under it - it would require a full update
for each of the children before the "file open" dialog was reponsive).  This
would probably mean I'd need to "queue" the status update, and return no
icon information to explorer.  This would mean *all* icon updates had to
come via an asynch "shell notification", which isn't practical for every
file in a tree.  So I could special-case files (ie, block explorer while
asking for file status updates, but not for directories), but that sounds a
little complicated, especially if an easier option exists.
 
> If we start out this way would it be particularly hard to change?  You
> said above that it's not blocking you yet, so maybe we should get it
> going just using one whole-tree scan and then if it is clearly the
> biggest issue we'll fix it.

At this stage it isn't blocking *me*, its blocking explorer ;)  My work
currently blocks explorer while a status request is made (and it only asks
for the part of the tree it is interested in, so works OK in many cases)
There isn't a reason we couldn't release a first version which continues to
do that and see what feedback we get (but I note the 3rd hand anecdotal
evidence we have got from tsvn users indicates we do need to take care here)

Regarding how much work to change: Its less work all round to not change
anything ;)  If we choose to stick with the fully-recursive model, we would
want to change the directory cache to take advantage of that - but the
"directory focussed" model inherited from TSVN should work OK for now.  I
would not need to implement a crawler (meaning we lose the background thread
and "suspend background updating for a moment" goodness), which is all less
work for me :)

To be quite honest, I really thought the whole non-recursive status thing
would be a fairly quick discussion and a few hours of implementation,
especially given that "todo" comment I referenced - and I've already wasted
more time than that on this topic.  Clearly its not that easy nor desirable,
so I think the approach above is an OK one to take for the first release
(ie, stick with what we have now), even if its suboptimal.

> Remember that tsvn has been around for quite a few years now, and
> while they've certainly learned some useful lessons in general some of
> them will be specific to the svn performance characteristics which as
> others have said are a bit different to ours.

I've thought about that since others have brought it up, but I remain
convinced that the things I've been discussing have been done by TSVN more
due to the specific performance characteristics of the shell it is embedded
in (ie, Explorer, common dialogs, etc) than SVN itself.

Either way, we have a system now that works, its just that in some cases it
is suboptimal.  I'm happy to work with that for now (but will probably
continue to reply to assertions that I couldn't benefit from it even with
the better relative performance of bzr ;)

Cheers,

Mark