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.
