On 26.04.2014 00:51, Les Mikesell wrote:
> On Fri, Apr 25, 2014 at 4:34 PM, Branko Čibej <brane_at_wandisco.com> wrote:
>
>> 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.
I'm talking about gigs of critical, versioned stuff. A working copy like
that can take a couple hours to check out. Build artefacts are just
cherry on the cake here. You may consider such working copies an extreme
case, but I've seen rather too many such extreme cases in real-world
deployments to ignore them.
>> 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.
You're confusing the contents of versioned files with working copy
metadata. The latter is never mostly read-only; even a simple "svn
update" that doesn't change any working file can modify lots of
metadata, and this is where locking is involved.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2014-04-26 06:59:27 CEST