will SVN save me disk space when converted from CVS?

Question

HI i am looking for a straight comparison of CVS to SVN. wondering mainly if SVN uses less disk space or more than the same in CVS?

Answer 1

A Subversion repository on the server uses a similar amount of disk space as CVS. It might be a wee bit more. However, on clients, Subversion (at least in the older versions) used quite a bit more disk space. This is because Subversion clients kept the original copy of each source file they downloaded. So, if you had 50 megabytes of source code, your Subversion working directory would be about 100 megabytes in size.

However, this really reflects the difference in the era when Subversion was written vs. programs like CVS.

In the old days, a developer might only have a 20 megabyte drive on their desk, and every byte of free space was precious. CVS used a checksum of the source file to determine whether or not the source file was modified. If the file in your working directory was changed, it would have a different checksum. However, it meant that if you did something like a diff on the file, CVS would have to talk to the server to get a copy of the original source file.

By the time Subversion was around, disk space was measured in gigabytes and was cheap. Thus, there was plenty of room for having a second copy of the original source file on your disk. Now, when you did a svn diff, you didn't generate any network traffic or have to wait for the server to respond. This greatly sped up development and the folks who designed Subversion thought the trade off was worth it.

The latest version of Subversion (version 1.7.x) has a different way it does the working directory on the client. I don't know enough about it to know how it works. But, to me, diskspace is a minor issue. If you need more, it's cheap enough to get more. What's not cheap is your time and effort in development. The easier and faster it is to do development, the better off you are.

CVS has not been updated in a long, long time. Subversion was designed as its replacement much the same way RCS was replaced by CVS. There is a whole cartload of reasons why you should pick Subversion over CVS. It's not because the people who worked on CVS were bad developers. It's that the people who worked on Subversion could take the over decade of experience with CVS to hammer out the issues CVS had.

• Subversion has atomic checkins and CVS doesn't. This in itself should be the deciding factor. In an age where we practice Continuous Improvement, Continuous Integration and Changesets, it is important for checkins to be atomic. If I modified 13 programs to fix a certain issue, and CVS only checked in 12 of them, the resulting build is bad. All the changes needed for a particular issue are not included.
• Subversion tracks file name changes and moves. CVS doesn't.
• It's easier in Subversion to back out changes. In Subversion, all I have to know is the revision number, and I can do it in a single command. In CVS, I have to gather the information, and try to figure it out. Plus, Subversion is way faster at reverting changes.
• Subversion branching and tagging is quicker. In many CVS sites, they do some really, really bad program practices just to get away from branching and tagging. What could take 40 minutes or more to do in CVS takes a millisecond in Subversion.
• Subversion works better with continuous integration systems. With CVS, a CI system has to go through the entire CVS directory structure looking for changes. In Subversion, the CI system only has to query the project's root directory what the last revision is.
• Branching and tagging in Subversion have their full history. You know who did it, when, and why. You can see if there were any modifications, and who did those, and why. CVS doesn't have this information easily accessible.

You can talk about Subversion vs. Git vs. Mercurial vs. Bazaar vs. Perforce and ask who is better. Each is a modern version control system and each has its own claim to fame.

However, Subversion vs. CVS is a no-brainer. CVS is a version control system that is no longer maintained and is missing what should be key features in a modern version control system. If it's a choice between CVS and Subversion, you put your money on Subversion.

Answer 2

In this case i converted the cvs to svn and found the file size on the hard drive, (it was on my own laptop at the time) but it was much smaller in svn, than in cvs, but there could have been some compression applied i dont know, but everything on the web said svn would actually be bigger than cvs.

so i think its a bit open to how the 2 are setup.