Subversion For Web Developers

Subversion For Web Developers

Another technology that should be employed by every web developer is source control (also known as version control). Source control is the management of source code files with specialized software that keeps track of every single revision of your source. When implemented correctly, source control brings many benefits to the web developer in business, personal, freelance, or academic projects. In this article, I will outline the process of implementing source control, specifically Subversion, and I will discuss the reasons why you will never want to develop without it again.

Why Use Version Control?

  1. Prevent big mistakes like file deletion, overwrites, etc.
  2. Checkout a version of the site from ANY point in the development.
  3. Keep separate versions of the site for stable, development, beta, etc.

Subversion

There are many reasons why Subversion is a great version control system. I’ll be completely honest, Subversion was the first and only option I considered upon hearing of the benefits of source control, so I don’t know much about the alternatives. Subversion was originally being developed through the Incubator project at Apache, but very recently graduated to an official Apache project and is now named Apache Subversion, which reflects its credibility as a leading source control system. Because it was developed to be an improvement on its predecessors, there are many features that make it better than the competition.

The Work Flow

When working with Subversion you will have to adapt to a new work flow, but trust me, it is well worth it. Once a repository has been created on your server (you’ll learn about that in a bit), you will need to “checkout” a copy of the code. This copy is called a “working copy” and when you are satisfied with your changes, you “commit” them back to the repository. My image below shows the cycle, although there is a better representation of it on Version’s homepage. Don’t get this confused with the FTP work flow. Instead of FTPing your site’s source code to your server, you will essentially be checking out a copy to your site’s root. Yes, this means your site is technically a working copy.

Collaboration is one of the benefits of using source control. It allows multiple developers to check out their own working copy of a site and work on the code simultaneously. When working in this sort of environment, you will need to be extra careful when committing your changes. If somebody has committed changes since you checked out your copy, your changes will need to be merged to prevent overwriting the other person’s progress.

Resources

For beginners using Subversion for development, I recommend leveraging the following services and softwares to make the journey easier. You’ll need an SSH client, a server with Subversion installed on it, and a programming environment or GUI (recommended) for making Subversion commands.

As a Mac user, I find the SSH terminal built into Coda best for interacting with subversion on the server. Coda also has built in Subversion control, which allows you to connect to your repository, checkout source, commit changes, rollback to a specific version, compare versions, and more. If you prefer a standalone application, or aren’t using Subversion for just web development, Versions is a great program which won the Apple Design Award in 2009. I chose Versions over Cornerstone but you might want to check it out as an alternative. In this tutorial I will use both Coda and Versions.

If you aren’t comfortable creating your own repository on your server through the very command-line oriented approach (I wasn’t and still prefer using a third-party repository host), I recommend using Beanstalk. With Beanstalk you can set up a free repository in no time and you can leave the more advanced features for later, when you are more comfortable with Subversion.

Getting Started

First you should verify that your website’s server is compatible. By this I mean it must have a suitable version of Subversion installed on it. You must also have the necessary privileges to use the SVN commands.

Begin an SSH session and login to your server. Run the following command to check if you have Subversion installed.

svn --version

If Subversion is installed, you’ll see something like this, otherwise you’ll have to install it or you won’t be able to use SVN to checkout your site on the server. Don’t worry, you can still get many benefits when using Beastalk as your host.

Start with a free repository from Beanstalk. This is the easiest option for getting started, and you’ll find it hard to switch to your own hosting (I still use Beanstalk). Choose to have Beanstalk automatically create the Trunk, Branches, and Tags folder structure. You’ll regret it later on if you don’t.

Once you have your repository set up, grab it’s URL from the repository page (located at http://<your_account_name>.beanstalkapp.com/<repository_name>). It is located in the right sidebar and looks like this:

Next, in Versions, create a New Repository Bookmark with the settings you set when signing up for your Beanstalk repository.

If you have a current site you are adding to the repository, select the bookmark and right click on the Trunk folder. This is where you want to import your files to.

Once the bookmark is created, select it and hit the Checkout icon to create a new working copy (on your Mac) of the repository. This working copy is the folder that you will do your editing in. Create a new site in Coda with the Trunk folder as the local root for the site. Don’t forget to enable Source Control and add the repository information (it should automatically find the repository URL if your local root is set correctly to the working copy).

You’re almost ready to checkout your site on your server. Before that, I want to give you a quick tour of Coda’s source control features. You can continue editing your site as you normally would. When you edit, you’ll see that files are marked as changed and you have the option of committing the changes to the repository. Some developers commit every small change as they go, but I prefer to commit all my changes after a coding session is complete.

Okay, it’s finally time to get your site running on your version controlled code. Commit any changes you’ve made since you imported your site files to the repository and switch back to your Terminal session. I suggest making a backup of your current site in case anything goes wrong. At the root of your site, run the following command to checkout your site code (assuming your site files are located in the Trunk directory for now). The dot at the end says to check it out to the current directory; replace the dot with the name of a directory if you want it to be checked into a new or existing directory instead.

svn co http://your_account_name.beanstalkapp.com/repository_name/trunk .

You should see a list of all the files in your repository fly by very quickly. Now your site is set up with your repository. Whenever you commit a change to your repository, you can simply run the update command to update the site to the most recent version like so (from the root of your checkout):

svn up

What’s Next?

Try using Subversion for a while before you go all out. Eventually you will want to look into “tagging“, “branching“, “merging“, and more, but those are all topics for another post.

Thanks for reading!

3 comments for this entry:

  • Paul

    Thanks so much for this article. It is perhaps the best “how to” for subversion I’ve seen online. I have everything set up as you stated (beanstalk, versions) and I use coda. I am now able to commit and all is working fine. However the problem I have is when I want to test my site on the localhost, I am unable to see the changes, as I am developing. The reason of course is that I have the site pointing to my trunk folder located outside of my “Sites”. Should i therefore Have my working copy within the “sites” folder. It seems I have to copies one localhost and one working copy!? So close yet so far and still slightly confused…I am nearly there I can sense victory. Thanks again for a great article, Paul

  • Ian

    Thanks for the subversion how-to man. I think I finally (finally) got it (for now). Now I’ll have to start looking at Mercurial and TextMate.

  • Andrew Dahl

    Very nice article. Just thought I’d make note of Mercurial. I think it’s worthwhile to check out, especially if you have extremely large projects and you enjoy branching. There are other pros to it, but that would be the most obvious.

    Also, if you’re a command line junky, git is pretty awesome. The learning curve tends to be steep, but you can do much more with it than any other version control system.

    Great article nonetheless.

Leave a Reply

Note: Use @reply syntax to notify previous commenters of your reply. User names are case sensitive.

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Friendly Sites

I recommend these links...