The Subversion Conversion

If you've ever looked for a blog on software development, you've undoubtedly stopped off at Joel Spolsky's little corner of the inter-web. And if you have, then you've probably read The Joel Test. That first item on it - "Do you use source control?" is something I'd like to talk about over the next few weeks.

If you use Visual Studio, you've at least heard of SourceSafe. Heck, you've probably used it, or are using it right now. Would everyone reading please raise their hand if they really, really like SourceSafe? Do you feel warm and fuzzy inside knowing your code is "protected" inside of SourceSafe? Anyone?

No? Me either.

So, what do you do? You can either live with it (not a good idea) or you can change it. Now, in an ideal world, you'd be able to either convince your boss/CFO/purchasing department to whip out the credit card and buy everyone Team System. Try it. If they react the same way most would (and to be fair, it is approximately 1 hojillion dollars per developer) then you've got to find something cheaper. Or, dare we hope, free.

Enter Subversion. It's open-source and free-as-in-speech, and best of all, some of the CVS developers that got tired of it work on Subversion. So you know they've got some background on the subject.

"But Nic", I hear you say, "isn't getting this running for a group of developers who are familiar with SourceSafe and doing things Their Way going to be a pain?"

Yes, probably. But, instead of dealing with quirks and worrying about database corruption and that offsite developer whining about how slow it is, my company decided to take a more pro-active approach. I'm a firm believer in Getting Things Done. And if I have to "deal" with my source control system, I'm not Getting Things Done.

So, go ahead and download the latest copy for your environment from here. And if you're using Windows, and if someone tells you that you must have Apache installed before you can use Subversion, they are either a LIAR, or simply confused. You only need Apache if you're going to be doing http/https-based access or want to do some fancy authentication (like Windows Domain). For testing on your local machine, you don't need it.

If you're a Windows user, definitely get TortoiseSVN. It's a Explorer Shell Extension that encapsulates just about everything you'd do with the command-line version into that pretty GUI that we Windows users need. If you're using Visual Studio, then you should also pick up AnkhSVN. It's a plug-in that will enable SVN commits/updates from within Visual Studio, and it knows not to check in your compiled DLL's, or the SUO files.

From my testing, I've found it best if you have all of the projects within a solution in the same working directory. This will probably not be the way that Visual Studio is doing things for you - it defaults to putting ASP.NET websites in one directory, and everything else in another. For both Subversion's sake, and your own, keep everything in the same directory. Cassini can run a website wherever you put it. If you're still building .NET 1.1 websites, you can also setup IIS to have a website wherever your working directory is, and the applications should get created automatically when you pull them down, or when you create new ones. I'm still experimenting with this, so please leave me some feedback if you have any insight on this.

If you're serious about taking this plunge, then I highly recommend you first go pick up Pragmatic Version Control: Using Subversion. It's short, and has a great overview of what someone who likes to Get Things Done should be doing with their source control system. It says version 1.3 on the cover, and 1.4 is the latest version as of this post. Nothing significant from a user's perspective has really changed, it's a lot of internal improvements, API changes, and some administrative enhancements.

Now, as far as a company-wide conversion, we haven't taken that plunge yet. But, we will. We need to figure out some best practices, repository structure/locations, and the general process first. So, stay tuned. We're in this together.