efficiency over NFS

[Mohit Aron]

>
>
>
> > 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/92ce849e/attachment.htm