To our surprise and disappointment, the speed of clean checkouts (by "clean" I mean checking out the entire codebase into a new directory, rather than simply updating an existing working copy) was underwhelming. CVS sets a hard act to follow here since one of its strengths is its speed, but I simply couldn't imagine Subversion claiming to be a compelling replacement for CVS unless it was equally fast. In fact, head-to-head, on the same platform, our tests showed CVS to be measurably quicker for clean checkouts.

What the trials did indicate was that disk access rather than network bandwidth was the main source of pain. Every time it checks out a file, Subversion replicates the base version of that file and its properties ^[1] into a hidden .svn directory, so for every 100 files you checkout, at least 500 files will be created on disk.

This replication is quite deliberate and is based on the principle that disk-space is cheaper than network bandwidth. Subversion makes full use of the cached file copies in your working area—so, for example, common operations such as viewing your modifications to a file, or reverting these modifications, do not require any interaction with the server.

What we found, then, on the performance side, was that the routine management of a working copy was much quicker. Clean checkouts took time, yes, but use of the svn update command keeps these to a minimum. In fact, the only user who frequently performed clean checkouts was our overnight automatic build.

Everything else went very well. Clearly, the authors of Subversion had done a great job in fixing the problems with CVS, and they'd done so -- at least from a user's perspective—by simplifying it.