After much gnashing of teeth, I've finally managed to build a bash script to automate deployment of my builds to production/staging for my in-progress website.
Note that the SVN hooks directory, as well as the working directories for the SVN must all be owned by the user that the hook script is executing as. In my case, the user was www-data, so I needed to run chown -R www-data /var/svn/repo/hooks, chown -R www-data /var/www/production, and chown -R www-data /var/www/staging. This also needs to be a post-commit script in order to function properly. Staging and production must also be manually set up as working directories. Staging should be on /trunk, but it doesn't particularly matter what production is set to, as it will soon change.
Now, my script isn't the most secure in the world, this I know. Mainly, because I've got the SVN username and password stored in plaintext in the script. At this point, though, I don't care. Here's the script!
#!/bin/sh
USER='username'
PASS='password'
REPOS="$1"
TXN="$2"
/usr/bin/svn update /var/www/staging --non-interactive --trust-server-cert --username-"$USER" --password="$PASS"
SVNLOOK=$(/usr/bin/svnlook history -r "$TXN" "$REPOS" /tags | grep "$TXN")
if [ -n "$SVNLOOK" ]; then
TAG=$(/usr/bin/svn ls "file://$REPOS@$TXN" "^/tags" | tail -1)
/usr/bin/svn switch "file://$REPOS/tags/$TAG" /var/www/production --username="$USER" --password="$PASS"
fi
What It Does:
$1 and $2 are the parameters automatically passed to the post-commit; the name of the repository and the revision number just committed, respectively. First, the staging site is updated to the most recent revision of the trunk (--non-interactive --trust-server-cert is used because my certificates have bad validation :P). Then, the script looks at the SVN history for the current revision, checking whether there's anything in the /tags directory. If there is a change to anything in /tags for this revision, we obtain the most recent folder, and switch to it on production.
The Result:
When you commit a change to the repository, the staging site is updated. When you tag a revision, the production site is updated. Thus, staging will always have the most recent (though possibly broken) build of the application, and production will always have production builds.