On Fri, Apr 25, 2014 at 4:34 PM, Branko Čibej <br...@wandisco.com> wrote: > > Working copies are supposed to be throwaway things that can always be > fixed to the last commit by the server. Why wouldn't you want to use > something fast, cheap, and highly buffered for that, even if it is > half baked? > > > Conversely, why would you want to put a throwaway thing on NFS?
Because it is quick and easy to export /home from a server with a big disk and mount if from a bunch of development systems. > To stray off topic for a minute here, though: the idea that working copies > are "cheap throwaway stuff" is less than universally true. I've seen complex > sparse working copies with many gigabytes of data, containing (unversioned) > build artefacts, that take hours or days to produce ... I wouldn't call that > cheap by any definition. Sure you can do that, but a typical design is going to keep the critical stuff versioned. > Still, none of the above changes the fact that NFS is not suitable for > high-volume, random-access, read/write applications. It's great for sharing > mostly read-only data, but a Subversion working copy, let alone repository, > does not fall into that category. "Mostly read-only" would be a pretty good description of mature project maintenance - which in my experience is where most developer time goes. -- Les Mikesell lesmikes...@gmail.com