The Reason for Change

Atomic Commits

Suppose a single logical change to the codebase—a bugfix perhaps— requires six files to be changed. The programmer makes the change and commits the new versions of the files to the CVS repository. Although a single commit command is executed, as far as CVS is concerned six changes have been made, and each individual file moves to its own new revision. If another programmer wishes to patch the bugfix to another code branch, all six files will need to be patched—but it's tricky to find this out from CVS. Information has been lost. Subversion solves this problem with a simplified change model: version numbers apply to the repository as a whole, and each change is a transaction resulting in a new repository version which logically corresponds to a whole new file tree.

CVS is an excellent source control system: fast, powerful and flexible. We had no concerns regarding its reliability and some effort had been put into integrating it into our automated build, test and release system. What's more, everyone in the team knew how to use CVS and how to work around its wrinkles. We all had our favourite clients. Why ever would we want to change?

There were a number of reasons:

The team had grown and so had the codebase. The CVS server no longer served high volumes of files as quickly as we'd have liked.
As the codebase grew, it had become apparent that some files were in the wrong places or had the wrong names. CVS supports versioning of files but not of file-systems, meaning that we couldn't fix these issues in a controlled way. Subversion fixes this CVS limitation.
CVS does not support atomic commits—another feature built in to Subversion.
Subversion sets out to be a "compelling replacement for CVS" and, after a quick skim through the documentation, it looked as though the transition would be painless.