On Wed, 12 Nov 2008, David Brown wrote: > > We had occasionally run into locking problems with 1.5.4.x with > renames between different directories. This should be fixed in > 1.6.0.3, but we have since migrated to a server model so I don't have > any way of testing this. I suspect it also depends very much on the particular client/server combination. Renaming across directories is one of those NFS things that some servers don't mind at all. > The configuration we did find completely unworkable was using git with > the work tree on NFS. Doing an 'lstat()' on every single file in the tree would tend to do that to you, yes. Even with a fast network and a good NFS server, we're talking millisecond-range latencies, and if your tree has tens of thousands of files, you're going to have each "git diff" take several seconds. NFS metadata caching can help, but not all clients do it, and even clients that _do_ do it tend to have rather low timeouts or rather limited cache sizes, so doing "git diff" twice may speed up the second one only if it's done really back-to-back - if even then. And once you get used to "git diff" being instantaneous, I don't think anybody is ever agan willing to go back to it taking "a few seconds" (and depending on speed of network/server and size of project, the "few" can be quite many ;) So putting the work-tree on NFS certainly _works_, but yes, from a performance angle it is going to be really irritatingly slower. I don't even think the newer versions of NFS will help with directory and attribute caching - the delegations are per-file afaik, and there is no good support for extending the caching to directories. That said, I don't think git is any _worse_ than anybody else in the "worktree on NFS" model. A "git diff" will still be superior ot a CVS diff in every way. It's just that when people compare to their home machines where they have the work tree on local disk and aggressively cached, when they then use a NFS work-tree, they'll likely be very very disappointed. Linus -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
