question regarding bazaar

[Talden]

> > >  If the matter is just that NFS working trees are somewhat slower than
> > >  local disk ones, I don't think such a state of affairs would indicate
> > >  that "you're not supposed to do that"; it's more like "if you do that,
> > >  you should expect somewhat reduced performance".
> >
> > The inconsistency of posix locking capability on NFS implementations
> > and the risk of becoming disconnected in the middle of a Bazaar
> > operation should be considered.
>
> As I clarified in the other thread, I don't want bzr to use locks when a
> 'bzr edit' is done. Its just a way to record in the local repository that
> the user is modifying a given  file. Later, a 'bzr status' or 'bzr commit'
> just needs to consult with this list and not do a stat on each file in the
> workspace.

Actually here I was referring to file-system locking and that poor
locking implementation could allow multiple overlapping bzr operations
(or a bzr operation and developer filesystem operation) to mess up an
NFS based working-tree.

> > Also I still don't quite get the model Mohit Aron's using.  If they
> > have a single central branch with a working-tree how do they avoid
> > developers accidentally committing or modifying uncommitted work of
> > other developers?  Surely they should still have their own workspace
> > (in which case they can have their own tree-less branch and a local
> > checkout solving the NFS working-tree performance problem).
> >
>
> We don't use a single working tree - each developer has his own tree (or
> workspace). However, this workspace is on NFS. We don't want to have a local
> checkout because one is not expected to checkin every line of code one
> writes - so there's a danger of the local disk crashing and one loosing
> his/her work due to that.

Which eliminates the concerns about NFS filesystem locking somewhat
although connectivity loss could easily have similarly severe
consequences (and would, I expect, have a higher probably of
occurrance than local disk failure within the development time between
commits).

I guess the issue then is the preferred workflow having large periods
between commits. If this is a necessary evil then perhaps the
unreliability of NFS connectivity is an acceptable risk when weighed
against losing developer effort spanning long time periods.

--
Talden