Saturday, January 20, 2007

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.

6 comments:

Matthias said...

"Your checked-out directories are 'clean' (no CVS directories)."

No?! Just as with CVS, you have a metadata folder called .svn in each versioned directory. Maybe you forgot to ls -a your sandbox? :-)

To get a "clean" project tree, you will have to "svn export" your files. Just as with CVS IIRC.

Humberto Moreno said...

This comparison is biased towards favoring SVN, obviously.

Unknown said...

SVN does not support tagging in a sense CVS does. You cannot give a named tag to a file.
Committing "all or nothing" however is an obvious advantage of SVN

KP said...

In addition to the loss of modules, SVN only allows directories to be checked out, where CVS let you check out individual files.

The two of these combined has meant writing shell scripts for building sandboxes, to ensure that not everything under the sun is brought into a repo.

I finally got annoyed enough with this to write a perl script which operates on my old cvs modules file, for checkouts, exports etc. Real time-saver.

It's not totally clear why the SVN team made decisions like these - when I've discussed the differences with SVN fans, they shrug, roll their eyes and say things like "You don't understand, it's a different philosophy."

I never have gotten an explanation for that philosophy (beyond the benefits of single revision numbers across repo), but I suspect that SVN is another project where developers convinced themselves that "REST is Right" no matter how limiting.

Anonymous said...
This comment has been removed by the author.
Anonymous said...

I recently did a presentation on SVN vs CVS, I have uploaded my ppt file on my blog. If anyone is interested he can check it here:

SVN vs CVS