efficiency over NFS

[Raindog]

Mohit Aron wrote:
>
>
>     No, but that is why checkouts and lightweight checkouts exist.  At my
>     old company, every developer had their repository on a central,
>     backed-up NFS server, and a lightweight checkout on local disk.  That
>     way, every commit they made was backed up, but they didn't have to use
>     NFS for their workspace.
>
>
>
> They were probably using the local disk because of bzr's inefficiency 
> in having a workspace on NFS.
>
> And if I do have a workspace on the local disk with the repository on 
> NFS, then I'll have to continously worry about commiting my changes so 
> that they go into the repository and are backed up by NFS. Its not 
> reasonable to expect one to do this every few lines of code that 
> he/she writes. Also, isn't the motto supposed to be that one should 
> think about the code and not about version control and backups ?
>
> I think 'bzr' should support an 'edit' command - if not by default 
> then as an optional extension. That way, people who believe in the 
> safety of keeping data over NFS can  use that model and people who 
> want to use the local disk can continue doing so.
>
>
> - Mohit
>  
>
Man, all I can say is that if a company that needs to develop in house 
software cannot come up with a better arrangement than diskless thin 
clients, I think I would be finding another job. The only scenario I can 
fathom an edit command being useful is when your repository is near the 
size/performance limitations of bzr which is pretty large. However, I 
might add, everyone I know who has used a VCS that requires the edit 
command *hates* the edit command and this goes for perforce, VSS and CVS.

That said, I think the one thing that can help solve the problem is to 
have some type of background service running that keeps track of 
external modifications to files under version control as this way bzr 
would not have to traverse a directory and build up data structures.