Is Subversion an enterprise-quality product?

November 7, 2006

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.

Advertisements

3 Responses to “Is Subversion an enterprise-quality product?”

  1. Mike said

    We started to use SVN recently at my shop. Even though we moved from CVS before, I’ve heard the same sort of rants about SVN here too. Personally I don’t see the problem. In every case that I’ve seen someone think that SVN was somehow broken they really didn’t understand how it was meant to be used.

    Just like Clearcase or Visual SourceSafe you need to understand how it is meant to be used otherwise you can get into trouble fast. I highly recommend reading the Subversion Book (http://svnbook.red-bean.com/) to help understand how it works and how it is intended to be used.

    SVN is actually a very mature and widely used piece of software which has repeatedly proven to be very fit for its purpose. It is clearly not just some “amateur” project.

  2. Don said

    We have recently undergone a major effort to switch from a ClearCase/Quest/UCM environment to Subversion/Bugzilla.

    This was due to what was deemed over complication and “crippled/broken tools” in our Linux environment.

    We suspect that our CC/CQ/UCM product was over-designed, with way too many requirements from too many groups.

    The Windows people were OK with CC/CQ, but we often see hard-to-recover from problems there as well (just try and undo a UCM activity).

    The bottom line is that we exported and implemented the CC environment into Subversion with a minimum of fuss… for the Linux people.

    The Linux people already understood the SVN (from their CVS days) mentality, and didn’t want/care about a GUI or version-trees.

    The limited triggers allowed us to implement a simple repository locking (start-commit), bug release/version requirement (pre-commit), and saving of change-sets in the bug (post-commit) mechanisms.

    So far, they have rarely gotten tangled up in such a way that “svn status” didn’t show what was wrong.

    Now it’s time to move the Windows people, and we’re having significant problems.

    TortiseSVN is OK as a GUI, but the version-tree doesn’t work the same (duh, because it’s not the same) and links are not supported correctly until Vista rolls out.

    I suspect it will be a much more difficult move for the Windows people.

    The bottom line is that you can’t make every set of developers happy.

  3. At WANdisco we have many enterprise class customers using our Subversion MultiSite (http://www.wandisco.com/subversion/multisite) product.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: