CVS and Subversion Differences

From CS Support Wiki
Revision as of 15:42, 9 August 2006 by (Talk)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Revision Numbers

In CVS, revision numbers are per file. CVS uses RCS (Revision Control System) as a backend, and each file has a corresponding RCS file in the repository. The repository is roughly laid out according to the structure of your project tree.

In Subversion, the repository looks like a single filesystem. Each commit results in an entirely new filesystem tree, so the repository can be likened to an array of trees. Revision 62 would refer to a particular tree - the way the filesystem looked after the 62nd commit.

In CVS, you may talk about 'revision 4 of source.c.' In Subversion, you would say 'source.c as it appears in revision 4.' In CVS, revisions 3 and 4 of source.c are always different. In Subversion, it's quite likely that source.c was not changed between revisions 3 and 4.


In Subversion, commits are atomic - they happen all at once or not at all. The whole change is applied (or rolled back) and is only visible to other users once completed.

In CVS, a commit alters each file in turn until it is done. This can lead to problems. For instance, if a network connect goes down in the middle of a commit, this can leave the CVS repository partially changed, and often unstable. If a user updates their working copy whilst another is committing a change, they may retrieve a partial commit from the CVS server.

Handling of Binary Files

In CVS, each revision of a binary file is stored separately, which can take up a lot of space. In Subversion, all files are stored as binary and an efficient binary diff algorithm (Vdelta) is used to compute the discrepancies between them. Thus, multiple versions of binary files take up less space than when using CVS.


In Subversion, directories are versioned, just like files. Subversion records the state of your files in a repository, which keeps track of the history of both files and directories. CVS cannot track history for a directory.

Renaming Files

CVS does not support the direct renaming of repository files, and cannot track version history of renamed files. To rename a file in CVS, you must do the following:

$ mv file1 file2
$ cvs remove file1
$ cvs add file2
$ cvs commit

However, the new file2 has no record of a common history with the old file1 (now in the Attic). In Subversion, the svn move command can be used to rename files.

$ svn move file1 file2
$ svn commit

Here, the common history of file1 and file2 is preserved.


Properties support is a Subversion feature that allows the user to attach metadata to any versionable object in the repository. This can include things such as mime type, whether the file is executable or not, etc.

Branching and Tagging

In CVS, branching and tagging are expensive operations for large repositories, as their cost is proportional to the number of files being tagged or branched.

Subversion makes both branching and tagging constant time operations. It doesn't distinguish between filesystem space and 'branch' space; branches and tags are ordinary directories within the filesystem. Both branches and tags are implemented simply by copying the directory you are tagging.