SVN vs CVS

This comparison is based on the following web
http://www.pushok.com/soft_svn_vscvs.php

Compared item	CVS	SVN
1	Repository format	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.
2	Speed	CVS works more slowly.	As a whole, due to some constructive solutions, SVN really works faster than CVS. It transmits less information through the network and supports more operations for offline mode. However, there is the reverse of the medal. Speed increasing is achieved basically at the expense of full backup of all work files on your computer.
3	Tags & Branches (!!! IMPORTANT)	To our point of view, these are implemented properly.	The SVN developers assert with pride that they have got rid of 3 measurements by working with tags and branches. In practice it means that they have substituted both concepts for a capability of copying file(s) or directories within the repository with saving the history of changes. That is, both tag creation and branch creation are substituted for copying within the repository. From the SVN developers' viewpoint, this is very elegant decision, which simplifies one's life. However, we think that there is nothing to be proud of. As for branches, everything is not so bad, now branches are nothing but separate folders in the repository, which earlier have had some interconnection. As for tags, everything is much worse. Now you cannot tag a code, this function is simply missing. Certainly, to some extent this is compensated by universal numbering of files in SVN, that is, the whole repository gets the version number, but not each separate file. However, we suppose you will not deny that it is not very convenient to store a four- digit number instead of a symbolic tag.
4	Meta data	CVS allows to store of only files and nothing else.	SVN allows to "attach" to a file any number of all possible named attributes. Excellent functionality, but it is not quite clear what it is necessary for.
5	File types	CVS was initially intended for text data storage. That is why storage of other files (binary, unicode) is not trivial and requires special information, as well as adjustments on either server or client sides.	SVN manipulates all the file types and does not require your instructions.
6	Rollback	CVS allows to rollback any commit in the repository, even if this may require some time (each file should be processed independently)	SVN does not allow rollback of commit. Authors suggest copy good repository state to the end of trunk to overwrite bad commit. However bad commit itself will remain in repository.
7	Transactions	In CVS the support of transactions by the principle "all or nothing" is completely absent. For example, when you checkin several files (transfer them to the server), it is possible that the operation will be completed only for some of these files, and will not be completed for the rest (due to conflicts, for example). As a rule, it is sufficient to correct the situation and to repeat the operation for the remaining files (not for all files). That is, the files will be checked in in two steps. No cases of the repository damage due to absence of this functionality were observed.	SVN does support transactions by the principle "all or nothing". Probably this is an advantage of the system.
8	Availability	Presently CVS is supported everywhere where you might need it.	SVN not yet so widly used, as the result there are places where it support still not implemented.
9	Internal architecture and code.	CVS is very old system. Initially CVS was written as bunch of scripts around RCS executable. Later this packaged into single executable. But internal structure of code is poor and have lots of historical fixes. Till now there was several attempts to rewrite CVS from scratch, but as it is known without success. We, personally, tried to extract client code to make better integration between plug-in and CVS, but without success. Right now we not think that CVS may grows too much in its functionality.	Subversion authors really spent some time on internal SVN architecture. Still not know how good are some decisions they make. But one is clear, the code is well expandable, and future improvements are coming.
	Total score	4	5