efficiency over NFS

[raindog at macrohmasheen.com]

My view on the issue is that there is a reason very few vcs systems' default behavior is file locking. The ones that have edit/lock are generally designed for giant repositories such ms windows 100's of branches at 15-25gb for lightweight checkout each. Virtually every other new vcs system I have seen does not encourage 'edit' because of general dislike of the workflow it requires

That said, I think the bzr devs could spend their time on issues that would imrpove user experience for broader ranges of users than I think edit would do.
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: "Mohit Aron" <extproxy at gmail.com>

Date: Thu, 6 Mar 2008 09:33:43 
To:"John Yates" <jyates at netezza.com>
Cc:bazaar at lists.canonical.com
Subject: Re: efficiency over NFS


I don't know NFSv4 well. I do know though that it is not as widely deployed as NFSv3. Even Netapp (which is the leader in NFS appliances) still sells NFSv3 solutions as far as I know.

That said, in general it seems to be a bad idea to issue a 'stat' on every file in the workspace whenever a 'bzr status' or a 'bzr commit' is done. Different people seem to have different opinions on this - I personally would much rather prefer that 'bzr' not rely on the performance of the underlying filesystem so heavily. That's why I'm proposing the 'edit' command as an option - whoever likes it can use it, rest can just use bzr the way it works currently.
 

- Mohit




On Thu, Mar 6, 2008 at 7:51 AM, John Yates <jyates at netezza.com <mailto:jyates at netezza.com> > wrote:
 Correct me if I am wrong, but did not NFSv4 address the issue of stat
 performance?
 
 If that is the case then this scenario applies only to those using older
 versions of NFS.  The number of shops creating these highly NFS-based
 environments, wanting to adopt cutting edge dvc technology, and yet
 unwilling to avail themselves of the benefits of NFSv4 must be rather
 small.
 
 /john