SVN vs CVS quick comparison

As it is known, before getting acquainted with SVN, our company had worked with CVS for long enough. We know CVS from both user and developer points of view. Approximately at the same level we had got acquainted with SVN, and undoubtedly we have an opinion to share with you concerning the question "what system is better?".

It is worth noting, that the work on the creation of the IDE plug-in for SVN had started at numerous user requests. However, our own motivation had also played a considerable role in starting work with SVN, since publications appeared that SVN is a substitute for CVS, which eliminates all its problems and shortcomings. Unfortunately, to our point of view, SVN is not a substitute for CVS and all the more it does not eliminate its shortcomings. Moreover, it even yields to CVS. Figuratively, CVS and SVN can be compared as C ++ and Java. Obviously, both CVS and SVN are more powerful than SourceSafe, as well as C ++ and Java are more powerful than Basic. CVS represents almost all functionalities of a source control system, though not always in a convenient and apparent manner. SVN, patching and expanding some CVS functionalities, simply does not contain some important functions. For example, the creation of tags and branches is dubious, and no means are provided to notify others that you are editing a file. It is similar to what the developers of Java have done: they have decided for you that pointers are not necessary, and there is no need in operator overloading etc.

Thus, as for now SVN cannot be considered a CVS substitute. It is a different system, similar to CVS. It has unique functions, which can serve as a reason for its usage. These functions make it more suitable for some development environments, for example for PowerBuilder. Below you can find comparative advantages and disadvantages of these systems. It is assumed that in relation to the remaining items the systems are similar. On the green background "advantages" of a system in relation to its competitor are presented, and "disadvantages" are presented on the pink ground. If you are facing the problem of choice, it is recommended to try both systems, paying special attention to the items below. You may also look to some discussion betwen Subversion developers and Pushok staff.

Note. This comparison cannot be considered as final, since both systems still developed. Last update was made for CVS NT 2.5.01 and SVN 1.2 at July 19 2005.

#	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