Scott Hanselman posted an interesting article about getting Subversion and Team Foundation Server to play together.

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."

Photo credit: http://flickr.com/photos/ern/471587728

I used Visual Studio back in the day. I was not only making a living by using Visual Studio; I was practically living _in_ Visual Studio. I used it for 10 or 11 hours a day. I loved Visual Studio (and still do).

But there was one piece of the Microsoft Development Kingdom that that I did not love: Visual SourceSafe. (Team System finally replaced good ol' VSS, but I had already started the switch to Rails by the time Team System was released). As much as I kind of hated VSS, I was used to it. And the integration that finally arrived in Visual Studio 2005 was really nice, like a quart of sugar covering a sour lemon.

The integration was *so* nice that I figured that the whole area of source control itself must be just as simple. I mean, come on. Check out, check in. How hard is that? I guess I had to create a new project folder in VSS when I really had to, and I suppose I had to add new files when I created them. But Visual Studio did all that for me. I more or less ignored the Check-in and Add To SourceSafe dialogs that would appear. I just clicked OK every time, and I was fine. I even learned how to do a diff pretty easily without leaving the IDE.

When I started to get serious with Rails development, however, I quickly came up against something people were calling "Subversion". All the cool people doing cool stuff on the Rails wiki used Subversion. The Rails Trac was using Subversion. Everywhere I looked all I saw was Subversion.

I was actually perplexed by it for quite some time. Of course I knew it was for doing source control and I got the command-line tool installed on my XP box. But the concepts were foreign, and I just didn't... get it. In fact, I was a bit miffed at how complicated Subversion seemed to be. It was source control, after all. I mean, come on. Check out, check in. It's not supposed to be this hard. How do I just freaking check out a file? It was frustrating.

In fact, there were a few elements of the typical Rails environment that presented steep learning curves like this. If I hadn't persevered through that initial rough patch Subversion, I know I would have felt justified in giving up on Rails and the whole open source scene along with it. It was tempting to go back to the familiar, safe, sugar-coated Visual Studio that I already knew.

But I'm so glad that I didn't give up. So glad. I don't know how I could ever live without Subversion. Or rather, I don't know how I ever lived with SourceSafe.

Uphill Both Ways

Looking back, I see why I had such mental difficulties. Seems silly to even talk about it now. But Brian and I try to blog about all of our .NET-to-Rails experiences, even the silly ones, so here goes.

My problem was that when I tried to first figure out Subversion, I was actually trying to climb two learning curves simultaneously:

• A new toolset: the subversion command-line tool and the TortoiseSVN for Windows; and
• A new mindset: a very different philosophy about how source control should work.

Those of you who, like me, are from the Windows side of the pond, probably know of Eric Sink. He wrote an excellent series of articles on source control systems. My problem was, I hadn't read those articles, and I had no idea there even were different approaches to source control.

I mean, come on, it's just check in, check out, right?

Wrong. And if you're already familiar to the VSS philosophy of source control, making the jump to Subversion can be discouraging.

So next time, I'm going to help you get Subversion up and running on your machine, whether it's Windows or your shiny new Mac. We'll even dip some toes in the water by getting the Rails source code onto your hard drive. (Ever wish you could do that with the .NET libraries?).

But first, I need a show of hands: how many of you out there are using Windows for your Rails development, and how many have switched to a Mac (at least for purposes of learning Rails)? Please drop a comment, with at least the word "Windows" or "Mac" so I can get an idea of how to focus the next article or two.