efficiency over NFS

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
> 

I do believe that this has been discussed. And there isn't a specific
reason why we couldn't do it.

Though you also have a significant failure mode that now the user needs
to track what they are changing, which is sort of what you are
advocating against in the first place :). (You are just shifting around
which part they need to track.)

I personally commit maybe 50 times per day, at any point that I have a
logical change. Because that also makes the patches more obvious to
read/track/merge/etc. I personally feel that is good behavior to follow,
even regardless of whether you have an NFS cache, etc.

I can understand helping users to work around behaviors. (A lot of
people don't commit often, etc.)

I certainly wouldn't have a problem merging a patch that allowed this as
optional behavior.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHz8iTJdeBCYSNAAMRAhCHAJ90sZ5SWFcF/rcltJR4LAO4ln7I5gCgpAWs
IMXquXhIOEs81xQCwFLjUcI=
=GJyt
-----END PGP SIGNATURE-----