Comparing SVN and CVS
When starting with a new project , first question which would come to your mind is which VCS to chose. Given a lot of options in market like CVS, SVN , Mercurial and Microsoft VSS , you have to look at you requirements.
If you are looking for something popular , easy to use , low cost and working with distributed teams, you should go either with CVS or SVN.
Here is quick comparison of various VCS used . This is a result of survey done in 2008 by finalbuilder.
Looking at the results, you would surely go with SVN but one should look at why SVN is getting more popular and is taking over CVS. SVN was created to fix some problems in CVS.
Here are some major differences :
1. Repository basis
CVS is based on RCS files of versions control. Each file connected to CVS is an ordinary file containing some additional information. It is quite natural that the tree of these files repeats the file tree in the local directory. Thus, with CVS you should not be anxious about data loss, and you can easily correct RCS files if necessary.
The basis of SVN is a relational database (BerkleyDB) either set of binary files (FS_FS). On one hand, this settles many problems (for example, concurrent access through the file share) and enables new functionalities (for example, transactions at operations performance). However, on the other hand, data storage now is not transparent, or at least is not available for user interference. That is why the utilities for “curing” and “recovering” of the repository (database) are provided.
What does this mean ?
CVS repository files are rcs-format files that you can easily understand and manipulate with a text editor. SVN repository files appear to me to be opaque blobs. If the file system gets partially corrupted, you may well be better off with CVS.
2. Tracking history
CVS only tracks modification file by file while SVN tracks a whole commit as a new revision, which means that it is easier to follow the history of your project. Add the fact that all modern source control software use the concept of revision so it is far easier to migrate from SVN than it is from CVS
3. SVN supports versioning of binary files
4. SVN adds transactional commit (all or nothing)
5. Subversion doesn’t distinguish between file system space and “branch” space; branches and tags are ordinary directories within the filesystem.
In CVS, branches and tags are different things. A tag is a label for a revision. They are pretty useful for things like marking a RELASE tag for files to sync to your webserver.
Branches live in the same ‘namespace’ as the main file — it’s easy to track down all the mods of a particular file.
6. Subversion can’t look at a file and tell you at what point someone created a branch or tag from it. Tools like CVSGraph can use this information to draw a tree of a file’s history. To do that with Subversion, you’d need to search all the branch/tags directories, and I haven’t seen any tools that do this well
7. You can move or rename files or directories cleanly in SVN
7. Commits are change sets on the whole tree (not just histories on individual files)
This post Subversion for CVS users can help answer your questions
Here is another link in wiki comparing CVS and SVN.
Updated : Subversion named sole leader in the Forrester 2007 Wave Report for standalone SCM
“Subversion’s strengths are scalability, administration, and geographical distribution. Subversion’s ability to scale to meet enterprise needs is well established, with single instances managing 7,500 users… Subversion is also easy to implement and administer: Subversion customer references reported initial implementation times of less than a month and administrator-to-user ratios of better than 1:1,000”, writes Carey Schwaber, Senior Analyst at Forrester Research, The Forrester Wave: Software Change and Configuration Management, Q2 2007