efficiency over NFS

[Talden]

On Thu, Mar 6, 2008 at 11:31 AM, Mohit Aron <extproxy at gmail.com> wrote:
>
> Hello,
>
> I'm evaluating switching from subversion to bazaar for my company. I had a
> question that I was hoping I could get some help on.
>
> It seems one can just modify files without telling bazaar about the intent
> to do so. And then 'bzr status' has to figure out what all is being modified
> - possibly by doing a 'stat' on each file in the repository. While this
> might be ok for a local disk, this is terrible for workspaces on NFS. I
> think future bazaar releases should consider supporting a mode where one
> needs to explicitly do a 'bzr edit filename' to tell bazaar that it is going
> to modify a file (same as perforce). Any other files that are modified would
> not show up in 'bzr status' - in fact, it might be better if files don't
> have write permissions unless one does an 'bzr edit' on it.
>
> Please note that a 'bzr edit' doesn't need to send any message across the
> network - it just needs to be recorded in the local repository. This
> differentiates it from a similar command in version control systems like
> perforce.

This is similar to the mechanism of scheduling changes for inclusion
in a commit.  So a status would be able to indicate changes that are
scheduled and those that are not.  The purist in me says this model is
preferable - I'm not sure that this is how most people work though.

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.

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.

--
Talden