Photo credit: http://flickr.com/photos/cmiked/318259785/

Thanks to everyone for the responses we got to Part 1. They covered a wider spectrum than I would have guessed!

Installation

• Main download page
• Shortcut to the binaries
• Windows Explorer integration

The main download page is a good place to start. Mac users can install from the binary or build from source if you're so inclined. The excellent Hivelogic article on installing Rails on OS X includes building Subversion from source on OS X.

TortoiseSVN on Windows is very cool and highly recommended. With it, you can just open up a folder in Windows Explorer and access all of the Subversion functionality by just right-clicking on a folder or file; in addition, icon overlays indicate at a glance what files you've changed since you last synchronized with the repository.

Windows users should also install the command-line client even if you install TortoiseSVN, especially if you're doing Rails development. Many of the Rails generators can take advantage of the subversion client if you've got it.

You can make sure your install worked by typing:

dev$ svn help

or on Windows

c:\dev> svn help

This should display the current version of your subversion client along a list of possible commands. You can get help for a specific command by typing (for example):

c:\dev> svn help checkout

which will display help on the checkout command.

It's important to note up front that some svn commands that are often used have abbreviated forms that will be recognized; like co for checkout and up for update. I tend to use the shorter forms, but you can se whichever form you prefer.

Getting Started

These are the two resources that got me off the ground. One is free, one is not:

• The Subversion Book
• Pragmatic Version Control with Subversion

I use the first one all the time when I forget stuff; the second one helped me get over my mental blocks I inherited from VSS. Start with the first one, and if you're still not comfortable, you may want to try the Pragmatic book.

Many people can read one or both of those and be on their way. Not me. I had too much VSS experience in my way. So I'm going to cover the basics of Subversion usage from my perspective - a former VSS user. (Hopefully some of this will still be useful to the rest of you, too.)

The SourceSafe Mindset

If you use Visual Studio in a team environment, someone gets assigned to be the SourceSafe "admin". The admin can create SourceSafe databases, add users, setup read/write privileges for each user, and so on. (Because God knows the built-in security features of the network and Windows servers isn't enough, so the SourceSafe team added yet another layer of home-grown administration hell). Each team member installs the SourceSafe client on their machine.

Using the SourceSafe client, you could create "projects" in the SourceSafe database. You could "Get Latest" on a project folder to get a read-only copy of the code onto your machine. It was recommended that you use the same folder names on your machine as was in the database, or opportunities for confusion and disaster reigned.

Most .NET shops go with the out-of-the-box defaults that SourceSafe provides, resulting in a particular approach to how developers on a team would use VSS to manage their source code and make sure that the source code repository would always be in a consistent state.

First, "Get Latest" would compare what's in the database with what I have locally. It would get a read-only copy for me of everything I did not have, and update any read-only copies of files I did have.

Already you can see a potential problem. If I had a writable copy of a file, SourceSafe would either prompt me if I wanted to overwrite my file (which I may have made changes to); or I could skip that file, leaving my local copy out of sync with the repository. Neither sounded like a good idea. If I overwrote my file, then I would lose my changes. If I skipped it, I would be annoyed that someone else updated a file that I was already working on, and now I'd have to figure out how to merge the changes together.

Which brings about the invention of the Exclusive Checkout. By default in VSS, only one person could "checkout" a file at a time. This avoided the scenario I just described. Before working on a file, I would "check it out", meaning that my local file would become a writable copy, and, no one else on my team would be allowed to check it out until I was good and done with it. Even if I left for vacation for two weeks; even if their changes wouldn't conflict with mine anyway; even if I didn't need to edit that file anymore. I was the only one who was allowed to change that file, until I was in a generous enough mood to "check it in".

When I finally did check the file in, my file would become the latest and greatest version, and someone else could now check it out.

What's Wrong With This Picture

The VSS mindset actually sounds logical enough. It sure did to me. But after a few years I realized that these usage patterns would appear on every team I was on:

• Work Sequencing. Because of the exclusivity on checked-out files, sometimes a developer would have to wait for another developer to be finished with a file. This was annoying when they didn't need to touch the same methods and merging the changes would have been easy. In these cases, developers would manually make their files writable, then manually merge their changes in later. And in fact the merge process was usually easier than it seemed. But usually the exclusive-lock mindset caused a lot of sequential development, not parallel development, slowing down the project. This effect was most pronounced at deadlines, because that's when a lot of ad-hoc bug fixing was going on.
• Lack of Communication. The exclusive-lock feature was a good tool feature but a bad team feature. The little lock icon took the place of developers talking to each other. Instead of everyone knowing what each other was working on, you'd hear faint cries of "Crap, someone's got MainForm.cs checked out." In order to solve the very occasional problem of two developers working on the same file, Microsoft decided to just make it impossible for two developers to ever work on the same file at the same time.

The Subversion Mindset

Some source control tools like Subversion take a different approach to enabling a team of developers to work together. Here's the basic idea.

On the server side, the subversion server exposes its repository through a file:// or svn:// url. Access is generally controlled through the usual ways of restricting server access over a network, and you can additionally require an ssh tunnel as well.

On the client side, everyone gets a writable copy of the source code.

Yes, you read that right. And no, I'm not on crack. Everyone gets a writable copy. Everyone can edit any code they want, anywhere in the project. At the same time!

This, Is Your Brain...

In Subversion, "update" means "get latest". ("Checkout" is similar, but you only need to do it the first time. In addition to getting the latest code, it also creates some hidden files so it can remember what the original url is back to the source control project that you're checking out.)

So when you "checkout" or "update" your code with Subversion, you're doing the same as a "Get Latest" from VSS. With Subversion, however, you actually get two copies of the code. One entire copy is stored in hidden subdirectories. This means that locally, in addition to your local edits, you so have a shadow copy of what was "latest" the last time you performed a "checkout" or "update".

When a developer wants to "check-in" their changes, they first make sure that they won't conflict with what's currently on the server. If there is a potential conflict, they must first merge the server's changes into their own local copy first. Run the tests, make sure everything still passes. Then they can go ahead and commit their changes.

But wait, you roar. I have to merge every time I want to check my code in? That's nuts!

Actually, I would estimate that at least 90% of the time on a typical software project, on a team of normal human beings that don't mind talking to each other, there won't be any conflicts at all for any given file. So 90% of the time, you can just "commit" your changes. In Subversion parlance, to "commit" means the same as "check in" in VSS.

There are no exclusive locks, and no waiting on other developers to edit a file. Here are the usage patterns I've observed so far with Subversion teams:

• More Work Gets Done. Changes to the same file by two different developers can usually be done in parallel anyway. Unless they are each changing, say, the signature of the same function - in which case, one needs to ask, why are they doing that if they claim they know what each other is doing.
• Many Operations Are Faster. Not only is it easier to work offline with Subversion, you can revert your code ("un-checkout" in VSS) and perform diffs without ever contacting the server, because you already have a local copy of what was "latest" when you did the last "update". So diffs, reverts, and knowing what needs to be committed, are fast operations.

What It Was, What It Is, and What It Shall Be

From VSS term to SVN equivalent:

• "Get Latest" => "update" (use "checkout" the very first time)
• "Check Out" => not needed! yay!
• "Check In" => "commit"
• "Diff" => "diff"
• "Un-Check Out" => "revert"
• "History" => "log"

Chaos Theory

The idea that there were no read-write locks on files sounded crazy to me. At first, I was convinced that utter chaos would reign under this kind of scheme.

Yet chaos has never materialized on any Subversion project that I know of (at least, not in the area of source control). In fact, the opposite seems to be true. The Subversion approach allows small teams, large teams, and even huge open-source projects to thrive. How can this be?

Next time, I'll show you step by step how to use Subversion to manage your source code. It's easier than it sounds. Soon you'll be thrilled with the new freedom that Subversion brings. You may even try to explain it to your .NET colleagues.

As long as you're prepared for them to slowly shake their heads at you and mutter, "Just say no."