SVN as a Web Site Maintenence Tool

Note: this is one of a series of posts about the creation of the King Design web site.

The more I use Subversion (SVN), the more I like it. The initial ramp up to understanding how a source control system works (and how to work with it) is hard, but the benefits are definitely worth it. Luckily, I have an SVN guru friend who is amazingly patient with my many questions.

When developing web sites in the past, I’ve set up local versions that I then push to the live or staging server. I’m very diligent about updating the local version then copying that to the server… until the site is live. Once the site is live, I’ll be making edits from different computers, different operating systems, etc. and those changes almost never make it back to my local version. It’s a total mess and I’ve lost work because of it.

The King Design web site was the first web site I built since I started using SVN, and I found it to be an invaluable development tool. Here are some of the benefits and ways I used it to create the King Design web site:

  • The main web site is a checkout of my kingdesign.net SVN repository. Changes I make on the server and changes I make on my local development copy can be checked in then distributed to the other checkouts. If I needed to test something live on the server, I’d edit the files over SFTP until I had them as I wanted, check them in, then SVN update on my local copy to grab the changes. SVN manages conflicts and versioning – one less thing for me to think about.
  • The demo and trial installations of Tasks are also SVN checkouts. I created branches of Tasks Pro™ and Tasks where I made the changes needed for the demo and trial installations. Then I checked those branches out into the King Design site for the demo and trial installations. When I upgraded Tasks Pro™ to version 1.5.1 and Tasks to 2.5.1 this week, it was a piece of cake to update the online demos and trials – “svn update”.
  • I do 90+% of my development on my PowerBook, and 90% of the testing I do on that development is done in Camino and Firefox. Once I have everything working as I want it to in a Gecko browser, I turn my attention to Safari and IE (Win). SVN made it much easier to make my IE specific changes. When doing my IE testing for the King Design site, I could edit and test directly from the PC then check in those changes and pull them back to the PowerBook and the remote server when they were ready.
  • The most obvious benefit to a source control system is it gives you both a backup of your work and the ability to go back in time in case you screw something up or need to retrieve something you’ve lost. Luckily I didn’t need to do this while developing the King Design web site1, but it’s certainly comforting to know I could have.
  • SVN (all source control really) allows you to create a snapshot of the site at a given time; this is called a “tag”. By creating tags at certain stages of development and as the site evolves, you can easily go back to a certain version of the site as needed.
  • SVN (all source control really) also allow you to create “branches” where you can make experimental changes or work on new development that isn’t ready to go live yet. You can then check out your branch to a staging location for testing, etc. while the main site remains intact.

Branching and tagging are very basic and common practices in software development, but much less common in web site development. It’s hard to stress enough the benefit of having your web site under source control and being able to take advantage of all these capabilities.

Note: it’s a good idea to deny access to .svn directories on your web server if you are doing SVN checkouts to your webserver. If you’re using Apache, you can add this to your httpd.conf or .htaccess file:

<Directory ~ "\.svn">
Order allow,deny
Deny from all
</Directory>
  1. I have had to do this with client web sites from time to time – thank goodness for source control! [back]