A Basic Subversion Work Cycle

Okay, so we’ve got a remote repository set up, and a local checkout. On your own you probably pointed your local testing environment to the local checkout and set up a database if necessary (importing a dump of the live database). So now let’s see how we’re going to edit our website using our new Subversion-based workflow.

The Basics

A typical work cycle, according to the Subversion Book:

• Update your working copy (svn update)
• Make changes (svn [add, delete, copy, move])
• Examine your changes (svn [status, diff])
• Possibly undo some changes (svn revert)
• Resolve Conflicts when working with others (svn [update, resolved])
• Commit your changes (svn commit)

In that second step is where most of our editing will take place. Go ahead and open up a file from your website’s local checkout in your editing app of choice. Make some changes and save the file. When you get back to the command line, type:

svn status

You should see your modified file listed with an “M” to the left of it. This indicates that subversion recognizes that the file has changed. The next step, and we’re adding this one to the above work cycle, is to test the change. So, using your local testing environment (MAMP?), open up the website and view your change. If you’re satisfied with it, it’s time to commit. Type:

svn commit -m "Made a change to file.php"

Changing your commit message to one that makes sense for the change you made. The message will be of help later if you find you need to undo or revert to this point in time. When you enter this command, Subversion will connect to the repository, update the modified files and transfer the changes.

As we’ve mentioned before, Subversion doesn’t know about a file unless you tell it. “svn status” will often tell you about files that Subversion notices but doesn’t understand, but it’s up to you to tell it what to do with these files. You can use the “propset svn:ignore” command that we talked about last time if the file is irrelevant and not to be committed. Otherwise, you’ll want to add it using “svn add filename.ext”. You can also specify directories and patterns with the add command. If you want to move, copy or delete a file, be sure to use the appropriate svn command to do it. You’ll get used to it after a while ;).

We’re not going to cover working with others yet. It’s possible at this point, though, to merge in other’s changes and resolve conflicts before committing. For more information, see the svn book.

Making the Change Live

Now we’ve committed our change, but this has no effect on our live website. This is good in that it gives us a buffer between our edits and the real thing, but once we’ve tested on our server there’s really nothing more we can do before we see it on a live server (sure would be nice to have our changes go straight to the live server and still maintain the benefits of revision control - gimme a sec).

The ideal situation would be to have a testing server that we can check in to first before going live. To do that, you would just do a checkout into the web directory of whatever you have set up as a testing server, and then after committing local changes, log in to that server and type “svn up”, which is short for “svn update”. If your live server is a working copy, you can do the same when you’re ready to go live with the changes. If it’s not, you’ll be using the “svn export” command to export a copy of the current revision without the .svn folders that litter the checkout. The export command can be used on everything from single files to entire sites.

A Little Automation

We can automate the update of our testing server (or live server if you’ve bypassed that step). Subversion has “hooks”, or the ability to execute commands dependent on certain actions taking place. We’re going to use the post-commit hook to make a shell command execute after a successful commit to the repository. This will mean that any time we commit from one of our local checkouts, it will execute the command, which in this case will cause the remote repository to update.

In order for this to work we need a couple of prerequisites fulfilled. The remote site obviously needs to be a working copy. As we discussed last time, you can just run a checkout and switch out the current web directory with the new checkout and you’ve got a live working copy (you’ll want to modify your httpd.conf to deny access to the .svn folders). You’ll also need to ensure that the working copy has appropriate permissions set to allow svnserve or apache to update it. If this isn’t possible, see the tip here.

The hooks are located in the repository directory on your remote server in a subdirectory called “hooks”. You’ll find a bunch of .tmpl files that serve as templates for the different scripts. For our purposes, we’re just going to copy post-commit.tmpl to post-commit and make it executable.

cp post-commit.tmpl post-commit
chmod 777 post-commit

Now we edit the file. Use your command line editor of choice/availability to edit the file. Leave the shebang line (#!/bin/sh), but you can delete the rest of the commented section and the existing variable definition lines (the rest of the file). Then we’re just going to add a line with the path to the working copy that we want to update. Because my working copy is hosted on the same server, I’ll be using a direct path to the working copy. Your needs may vary depending on your setup. Also verify the location of your svn with “which svn”. You’ll probably want to define an absolute path to the executable because the script will be executed without a PATH variable.

/usr/bin/svn up /var/www/vhosts/circlesixdesign.com/httpdocs

Save and close the file. Next time you commit from your local copy, you should be able to view the live copy and see the changes almost immediately after you receive confirmation of the commit on your local machine.

You can read more about hooks in Chapter 5 of the Subversion Book. Hopefully you’re all giddy about using TextMate to make this process a little easier. I’ll take a look at that along with a couple of graphical alternatives next time. We’ll even mention a few alternatives to Subversion for those who just haven’t been turned on by this so far.

development» Geekery» MAMP» server» svn» tutorial» web»