efficiency over NFS

[Talden]

> > I can see how this would help performance wise for commits, it
> > wouldn't help any other operations though - and I'm not sure what the
> > scenario is that would suit using NFS for a working tree.
>
> It would help for commits, and it would also help for 'bzr status' - I find
> that I do that a lot to find out the locally modified files in my workspace.

I disagree that you'd make status cheaper.  What you could make is a
cheap 'scheduled' command that only lists paths scheduled for commit.
You still need a status command that can tell you how the entire
working tree differs from the working tree revision - this is because
there is nothing to stop users or applications making changes to the
tree or tree contents without scheduling them for commit.

Does anyone know how git works in this regard - my understanding was
that a 'status' still walked the tree.

--
Talden