Why I’m Using Subversion

Before I get too far into the Subversion series, I think a little explanation is in order. So if you’re wondering why you would want to use Subversion (svn) for web development, let’s take a look at typical development processes and examine pitfalls and shortcomings, and then see where svn can help us out. This is part 1.5 of the series because I forgot to plan it in to the original lineup. I guess I just assumed that everyone WANTED to use Subversion (silly me)…

My Old Workflow

My old workflow worked, but it was a mess. I’d build a site on my local machine, run it as a testing server until it was mostly ready for production, then put it on a production server for final testing. I’d make changes using remote editing and then copy the files back to my local machine. If I made a change that broke something else and didn’t realize it, I’d have to either hope I hadn’t yet overwritten the files on my local install, or start figuring out where I went wrong by hand. Using the Edit in TextMate function in Transmit is cool, but dangerous.

The Dreamweaver Setup

The typical Dreamweaver setup is essentially the same, except for it’s mirroring the site before editing the file. You still lose your previous versions, and have nothing to diff against when things go wrong. Its one benefit is that it’s set up a little better for workgroups and requires less fiddling to lock files, but still lacks the ability to revert to previous versions.

Subversion to the Rescue

Subversion itself won’t fix your workflow, only aspects of it. It does, however, provide the framework for an improved system. It gives you the ability to branch off of your main install and try something new, merging it later if it works. It gives you the ability to have a local checkout, a testing server and a production server where you only have to edit locally and update the two servers as necessary. You can even assign a post-commit hook to automate the update of the server(s), but we’ll get to that later.

Primarily, Subversion does what it’s built to do: Revision Control. Every time you commit a change, it stores 4 important pieces of information: WHEN it happened, WHO did it, a DESCRIPTION of the commit and WHAT changed. Each commit gets an integer revision number and you can diff against and revert to a revision when you need to.

It also allows multiple people to work simultaneously and merge their changes together. It also handles your file transfers, including binary files. It will keep track of all those extra images you added and remind you about dependent files you may have created in a forgotten subdirectory. It can take a lot of pain out of the process of developing and maintaining a website.

It has its downfalls as well… not the most efficient file transfers, for one. However, I can check out my entire blog repository in about 10 minutes over a broadband connection, and it’s a few hundred megs. So it doesn’t suffer much. You also have to stick with the system, as working outside of it can quickly lead to a mess that you don’t want to clean up. It also takes some planning and care, especially in the case of sites that create their own files (cache) or modify files dynamically (config). But it has methods for handling all of that, which we’ll cover.

Next up is a look at installing Subversion on OS X and Linux, with links for the Windows folks. Then we’ll look at creating our first repository and making a local checkout. If you’re with me so far and have any specific questions, let me know.