<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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.</blockquote><div> 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.  </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Can you explain the workflow and reason for using NFS? Capturing these differences in needs would be good if it  exposes realistic functional gaps.  It might then be possible to document known issues, workarounds and recommendations to lessen the pain or at least give those more aware of project roadmap intentions a chance to speak on the appropriateness of the tool for now and the near future. </blockquote><div> Sure. Take the example of a typical company that has a centralized repository and many developers using that. The developers may choose either the centralized workflow, or the decentralized workflow with a shared mainline (as explained in <a href="http://bazaar-vcs.org/Workflows">http://bazaar-vcs.org/Workflows</a>). Now the issue is that a developer can't be expected to do a commit and push to the centralized repository after every line of code that is written by him/her. So until the code is pushed to the centralized repository, there is a chance that the changes can be lost due to a disk crash if the developer were to keep his/her bazaar workspace on the local disk. This is where NFS comes in. Its much preferable to keep the workspace on NFS, so that it is automatically backed up by the IT staff (as is done typically in companies). A centralized NFS server is also far more robust than the local commodity hard disk is. Now as I explained, issuing common commands like 'bzr status' and 'bzr commit' when the workspace is on NFS could be extremely slow as bazaar would check the status of each and every file in the workspace over the network. On the other hand, if the developer can tell bazaar about the intent to modify a given file using 'bzr edit', then bzr doesn't need to scan the whole workspace when the user issues a 'bzr status' or 'bzr commit'. This will be a big win for workspaces over NFS. As an extra, I'd also like bazaar to make files in the workspace read-only by default and only make them writeable when one does a 'bzr edit' on them. This functionality is also very like perforce - it prevents mistakes where one modifies a file but forgets to tell bazaar about it using 'bzr edit'. - Mohit  </div></div>