Converting from CVS to SVN: Developer's Notes And Why SVN Is Better

Posted by Artem Russakovskii on July 15th, 2006 in Programming

Updated: July 17th, 2006

Hey there! If you are new here, you might want to subscribe to the RSS feed to stay up-to-date with all this techy nonsense.

(Work in progress) Last week at the new company I got hired at, I was trying to push the repository approach to developing and maintaining data. For one reason or another, it wasn't being done at the time. As a CVS user and admin, I wanted to set up CVS but decided to explore other options as well, including Perforce and SVN. Well, the choice between those 2 was easy: SVN is completely free while Perforce allows only 2 licenses with $800/license beyond those 2. My first SVN impression was that it's quite different from CVS, but in a very good way. Now that I'm actively using it, I'll be adding my thoughts to this page in the form of short paragraphs. ALL COMMENTS, WHETHER CORRECTIONS OR REFLECTIONS, ARE WELCOME.

First of all, SVN can be accessed using http protocol right in the browser by default. But this is no ordinary read-only web view (like ViewCVS). No, no. Any SVN action can be done through http, including commits. So as long as you have apache running on the server and you can get to it using a browser on the client, you can fully utilize SVN. And did I mention that SVN can utilize a full spectrum of user access permissions (internally, the server uses .htaccess)? I believe that in CVS additional setup of, let's say, pserver would be needed to make it available outside of the local filesystem.

SVN's revisioning is completely opposite the one CVS uses. For example, in CVS every file has a revision, so when I check out the latest from the repository, I receive a set of files with their own versions. In order to easily check out files from the past, I would have had to tag them or use the checkout by date, which is a pain in the a$$. In SVN, however, each time I commit something, there is no per-file versioning. The only revision number is the one for the whole repository, and it increments on every commit. It's like giving a new tag to CVS after every commit. The revision numbers will quickly run up to thousands, but in my opinion it's a much better approach to versioning.

Here's what the SVN book has to say about this:

In Subversion, the repository looks like a single filesystem. Each commit results in an entirely new filesystem tree; in essence, the repository is an array of trees. Each of these trees is labeled with a single revision number. When someone talks about “revision 54”, they're talking about a particular tree (and indirectly, the way the filesystem looked after the 54th commit).

Technically, it's not valid to talk about “revision 5 of foo.c”. Instead, one would say “foo.c as it appears in revision 5”. Also, be careful when making assumptions about the evolution of a file. In CVS, revisions 5 and 6 of foo.c are always different. In Subversion, it's most likely that foo.c did not change between revisions 5 and 6.

● ● ●

Artem Russakovskii is a San Francisco programmer, blogger, and future millionaire (that last part is in the works). Follow Artem on Twitter (@ArtemR) or subscribe to the RSS feed.

In the meantime, if you found this article useful, feel free to buy me a cup of coffee below.

beer planet