Why Subversion is better than CVS for Java developers

Over on the JDeveloper forum, John Stegeman responds to a question about whether CVS or Subversion is better for Java development:

... "Subversion," especially if you are using ADF business components. My reason for saying this is that we initially tried CVS [in an environment where] the network was not the most reliable. We had some problems where the network would drop in the middle of the commit (not a JDev/CVS problem), and half of the changes would be committed to the repository, and half of them were not. In the case of the Business Components, having the XML files and Java source files out of synch was a major major problem. This particular problem is one that Subversion solves; with Subversion, either the whole commit happens or none of it happens, just like a good database.

He makes a very good point. Atomic commits are one serious advantage Subversion has over CVS. In Java applications, where you tend to have a lot of files (as opposed to C where a lot of logic is concentrated into a smaller number of source files), it's vitally important that all of your changes are submitted along with each other.

Another big advantage of Subversion compared to CVS is directory versioning. In Subversion, directories have versions, just like files. The history of a directory is tracked over time. In the Java world, we like to move stuff around a lot (let's refer to it as "refactoring", although that word has additional implications). It's nice to use a version control system that does a good job of handling complex move operations over time without resetting element history.

AddThis Social Bookmark Button


  1. Pretty much the only reason to use CVS these days is because you registered a project on sourceforge before they supported Subversion, and even then, you can migrate.

    I was a great fan of CVS in its day (WinCSV rules!), but it is 2007, and atomicity has to be a given....

  2. One more reason why I like svn is that, it is not the individual files that are versioned. It is the whole project that is versioned.

    This way you don't need to know a particular version of a particular file, rather you need to know, a file in the particular version of the entire project. This simplifies things a lot.

  3. I love that you can use https to access SVN, which makes it much easier to use through firewalls. On the other hand, commits and updates are much, much slower.

  4. A reason *not* to use SVN is that you can't get up-to-date binaries for the Mac. And you can't compile it because you can't check out the code from SVN.

    When SVN is supported on the Mac (and by supported, I mean a binary that I can download and install), I'll switch to using it. However, at the moment, it's Linux/Windows only.

  5. As alblue subsequently noted on his blog, you can now get an "official unofficial" Mac OS X build directly from CollabNet.

    Prior to this, I'd been getting Subversion from one of the guys at Coding Monkeys (the SubEthaEdit people); he's done a good job of staying up to date, with 1.4.3 currently available.

  6. Agreed with the of benefits that you listed like atomicity and folder versioning..etc.

    But one thing is still missing in SVN, history across the branches in a single view. It is supported in CVS.

    That's the only reason of my dislike of SVN.