Subversion vs. CVS

I recently decided to take subversion for a test drive. I know a couple folks who are using it and were pleased, and I was tired of some problems with CVS (e.g. having to hack the repository by hand for moves, stupidity with binary files, the pollution of my file namespace with "CVS" directories, ...).

Short version of the result: steep but short learning curve, immediate vast improvement in productivity over CVS.

Longer version:
The "CVS to SVN" howtos don't tell you some of the info you really need to know.

1. Subversion makes an explicit distinction between data and metadata ("properties", in svn). CVS uses .cvsignore files,
   SVN uses svn:ignore properties which you have to set up yourself. This bit me in a weird way-- I had put some JPEG files into CVS but forgotten to set -kb so they became corrupted. I noticed this during my check of files after importing into subversion, and copied correct versions over the corrupt ones in my working subversion directory-- but committing did nothing. This is because subversion helpfully set up file properties for these files that marked them non-binary; these had to be removed using

   svn propdel eol-style
   svn propdel svn:keywords

   before fixing it up with

   svn propset svn:mimetype application/octet-stream file.jpg

   Then, it works correctly.
   
   
2. Subversion doesn't have modules. In CVS I had a separate directory in my CVS root for each project, and could check out and commit independently. Importing this into subversion makes one repository, and committing to one project bumps the revision number on the entire repository. There's nothing technically wrong with this, but it's confusing-- when you 'update' a project and the revision number goes up, yet nothing has changed. To get the same behavior as CVS, you need to create separate repositories for each independent project.
   
   
3. Subversion doesn't like man pages. Everything is via [command] help. This is just annoying because you can't get all the info in one page to search through, you have to interact with the program's help system.
   
   
4. Subversion's repository can only be mucked around with through commands, or worst-case through a text file dump of the same. At some point, I guarantee you will have to hand edit a dump file. You will need to learn their syntax (which isn't so bad) but it's not like going in to CVS and doing file operations.
   
   
5. Subversion likes URLs for some commands. Even if you're running on localhost. And they're not too consistent on when to use one, and when another. This kills tab-completion on my shell. Annoying.
   

But once you get beyond that stuff you find it's pretty slick.

• Moving files is possible-- restructuring your source code tree is easy rather than darn near impossible.
  
• Branching is trivial.
  
• Your checked-out directories are 'clean' (no CVS directories).
  
• You can do lots of things disconnected due to the file caching mechanisms.
  
• Atomic commits.
  
• Vastly improved logging mechanisms, log-per-commit.
  
• Status checking.
  
• Knowledge that the tool has active developers and is only going to get better rather than die a slow painful dragged-out death.
  
• "Coolness" factor.