Subversion is no Clearcase

I have recently begun a consulting stint with a large firm that is using Subversion (SVN) for its source code control system. This is the first time that I've used SVN in anger, although I've heard a lot about it - all of it positive.

SVN is the first time I have used a piece of version control software that uses the Modify-Commit model - that is, you can modify any file under version control, but you have to Commit those changes before they become part of the file's history. This model is also used by CVS, on which SVN is based.

The alternative to Modify-Commit is the Checkout-Checkin model, where a file has to be explicitly set for writing, or "checked-out", before it can be modified. The file is then "checked-in" to store the changes in the file's history.

It has taken me a while to get used to the M-C model, and I don't really like it: I like to have files set to read-only until I explicitly say that I want to edit them.

Another difference between SVN and Clearcase is the repository-wide versioning model. If you modify a single file in SVN, and then commit that change, a new version number is applied to the entire repository. Files that are completely unrelated to the change are marked with a new version number. This makes the revision graph virtually useless. In contrast, the Clearcase version tree browser is the most useful piece of functionality I have ever come across.

The merge-comparision and conflict resolution tools in SVN are pretty dire, far less intuitive than the Clearcase "merge manager" (or "merge mangler", to its friends).

The biggest problem I have with SVN, however, is the branching model. When creating a branch, and doing a "checkout" to get the latest files, it is far too easy to create your files in the wrong directory structure, since SVN doesn't enforce any kind of directory level on you. In contrast with Clearcase, where any static views are created in "C:\Clearcase\vob-name\". This is one occassion where I'm happy to trade flexibility for consistency. I need to know that the half-hour checkout process I'm about to undertake is going to end up in the correct directory.

Clearcase allows you to create branches from any point in your source-code repository and then merge them back into your "main" branch. Likewise, SVN allows you to create branches from your "trunk" branch and then merge them back in. SVN, however, doesn't properly version the directories themselves. This means, for example, if you add a new file ("newfile.cs") to your branch directory, and then merge your changes in to trunk, "newfile.cs" does not appear. Instead you get the error "Skipped missing target". I haven't yet figured out how to get new files merged from one branch to another, short of manually copying the files and then adding them in.

My final issue with SVN is one that applies to most open source software, and that is "fitness for purpose". I have managed to get SVN to tie itself in knots a couple of times, which have meant I've had to delete the .svn directories, back up my changes, re-checkout and then apply my changes manually. Basically, the SVN equivalent of a "blue screen of death". That is OK if I'm working on an personal project, or perhaps in a very small team on a limited codebase. Unfortunately, on a global project, with millions of lines of code, and teams of developers working in different, to sometimes differing agendas, it creates chaos. Also, the documentation available is very limited, and in some areas it is non-existent. More-than-trivial-branching is one area where I feel I am "writing the book" on it. Again, that's fine in a personal/amateur environment, but at the enterprise level it is simply not sustainable.

SVN is OK, and as a piece of software I am sure it is a great technical achievement, but it is not an enterprise level source control system, and it should not pretend to be one. In the final analysis, SVN's shortcomings are not the fault of SVN or its programmers, they are the fault of the decision-makers who decide to take an amateur open-source product and trust a multi-billion dollar firm's entire codebase to it.