We begin our story here: our hero decides that he needs to let external clients access parts of his source code management system. Currently using CVS to manage his code, he is haunted by the task of this external client accessing select parts of the repository. Although he thinks he may be able to somehow do it with unix permissions, that solution seems both limiting and scary.

Also, a lighter weight method of viewing the code would be nice (where lightweight means “not having to checkout the entire repository onto their machine, or use the somewhat clunky ViewCVS.

Our hero, knowledgeable in the ways of code management, knows that Subversion is labelled by some to be “CVS with out the suck.” After installing subversion, our hero looks around at the greener fields, and wonders why he spent so much time working around CVS’s faults.

Reasons SVN doesn’t suck

• Repository Wide Revisions

  In CVS each file has a revision number - you can see that foo.h has changed 10 times, since it’s number is 1.10. But often, in a big project, changing one file means changing other files, since these files all interact together. In this big hypothetical project, if one of your coworkers changed a file that also interacts with other files, you have to not just revert to the previous version of foo.h, but of bar.h, list.h, engine.h, and also app.cpp. Now, there’s no good way of keeping track of what files were changed in one particular checkin, so your team has to define some sort of system… or pray that the changes really weren’t that extensive

  Subversion solves this “what versions do I need to check out to get this project looking like it was before Bob screwed up my code?” question very easily - files don’t have version numbers - repositories do. This means when Bob checks in his latest changes (foo.h, bar.h, list.h, engine.h and app.cpp) the version of the repository itself gets incremented. So, reverting your code back to before Bob made his disastrous error is a simple, one line command (instead of a maze of complexity). This also means your terminology changes - instead of saying “Version 1.5 of foo.h”, you say “foo.h as it appeared in version 5 of the repository”.

• WebDAV access built in

  Sometimes you need to access your files on the go. Maybe you don’t have the latest schematics on your laptop. Maybe you don’t have your machine there - or maybe you want to somehow provide the absolute latest version to someone - simply. Subversion fills this need by using WebDAV - just mount the repository like you would any other WebDAV share, or use a browser! Using standard WebDAV methods, this will show you the latest version of the repository, no matter what. Via Subversion clients, also using WebDAV, you can check out arbitrary revisions of the repository, but, of course, standard WebDAV methods don’t have the interface to provide that functionality.

  WebDAV is also great because it’s a standard - every operating system provides some form of WebDAV access.

• svn switch

  Ever tried to change the path to a CVS repository? Or switch to a different branch in a working repository? Hard operations in CVS, right? Do them both with one command - svn switch does both.

• More Offline Operations

  Ever want to revert to the latest revision when you’re away from the network? Can’t do it in CVS. Subversion, on the other hand, keeps copies of the files in the repository on your disk. This means lots of things - first, operations like svn diff, and svn revert don’t require a network connection. Secondly, it means that Subversion can compute diffs and send those to the server, instead of having to submit the entire file back to the server to commit it, like CVS has to.

• SVN Tells You Stuff

  Subversion will tell you when you’re adding a binary file (which is helpful when subversion guesses wrong - you can even set it to text if you need to!). When does CVS add a binary file? Whenever it wants

• SVN Won’t Let You Commit Conflicts

  I do a fair bit of CVS merging, so I know when I say that CVS merging sucks. It really sucks merging lots of files - like merging two different source directories together. I two different scripts that help things along, but I’m always worried that I’m checking in files with conflicts, and that it’ll come back and bite me in the rear years from now.

  Now, here’s the thing about subversion and conflicts - it won’t let you check in a file with conflicts. You try, subversion will tell you that there are conflicts in the file and refuse to go further. Thank you for saving me from doing stupid things, subversion.

• Subversion remembers your passwords

  Yes, it’s true - subversion will cache your passwords. CVS seems to ask for your password every operation it does - with subversion, enter your password once (to check out the repository), and you’re done - forever. Thank you for making user’s life easier, subversion

Now, the bad news: ways SVN sucks:

• Repository Wide Revisions

  Sometimes a repository really is a set of marginally related files. A set of config files, a set of shell scripts, or anything else. Sometimes you just make a typo in one file and have to fix it. It feels almost frivolous to increase the version of the repository for a small change. Yes, it’s all mental. Yes, I’ll get over it - but I’m not sure I like it.

• Subversion Depends On Lots Of Software

  To build subversion you need a fair number of large software packages. Apache, Neon, APR, and Berkley DB. You’ll want to use something like DarwinPorts to install subversion - even if you’re a Unix junkey.

• Subversion uses directories for trees and tags

  This seems like a hack to me. Subversion allows you to associate properties with a file or folder - why can’t I use properties to tag a set of files, instead of creating a directory in my repository?

• I miss my CVSROOT

  Say what you will about CVSRoot, the module where CVS stores it’s administrative information, it is fairly easy to change the information stored in these files. An example is creating a module alias - being able to cvs checkout help and have the Documentation module be checked out. This is easy in CVS - one line fix. In subversion, however, this means configuring your server - if you’re using Apache as a front end this could mean adding 10 lines of additional configuration information to your httpd.conf. Not quite as easy as CVS.

Those are my thoughts on Subversion. For me and my company, it’s a great solution - over the next year or so I plan to be phasing out our CVS repository and moving all projects, albeit slowly, to subversion. Greener fields await.