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
