efficiency over NFS
Mohit Aron
mohit.aron at gmail.com
Thu Mar 6 06:45:44 GMT 2008
> 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.
>
>
> 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.
>
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 http://bazaar-vcs.org/Workflows).
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20080305/b1bbd58c/attachment.htm
More information about the bazaar
mailing list