Coding with Jesse

Update a Dev Site Automatically with Subversion

January 19th, 2008

If you're using Subversion during development (and you really should be using some kind of version control system), you can wire it up so that your development site will be updated automatically every time you commit a file. And it's easy!

Well, it's really easy if your subversion server and development web server is the same. If it's not, it's still possible, but outside of the scope of this article. You'll also want to be familiar with the command line, shell scripting and Subversion before attempting this stuff.

The first thing is to make sure your development server is a Subversion working copy, or in other words, that you can go into the dev site folder and run "svn update" to update the site. So if you've been using "svn export" or something painful like FTP, you may need to replace the dev site with a folder created using "svn checkout".

Okay, once you can update the dev site using Subversion, all you need to do is edit or create a file called "post-commit" inside the subversion repository, inside the "hooks" folder. If you look in that folder, there will probably be a bunch of example files like "post-commit.tmpl". These are examples of what you can do. Create the post-commit file by copying over the example, like "cp post-commit.tmpl post-commit", then edit this post-commit file.

Inside that file, there will be some example code like:

/usr/lib/subversion/hook-scripts/ "$REPOS" "$REV" [email protected]

You'll want to remove or comment out this line and stick in your own scripting. You can put any commands in here that you want to run after each commit. For example, to update your dev site, you might have something like this:

cd /var/www/path/to/website
svn update >> /path/to/logfile

That's it!

If you run into problems and you used the logfile like in the example, you can have a look in there are see if there are any error messages. I often have problems with permissions, so you may want to change the permissions in the dev folder (eg. chmod 770 -R *).

This works really well when more than one person is working on a set of files. Instead of 7000 files like "file.html.backup_jesse_19-01-2008" you can just commit and see the changes instantly. It might seem annoying to have to commit files every time you make a change, but it's the same if not easier than uploading files over FTP every time.


1 . Emil Stentsröm on January 19th, 2008

Emil Stentsröm

Great article, I had no idea that there were hooks that subversion can trigger. Will certainly use this in projects in the future. Thanks!

2 . Pete on January 19th, 2008


Nice writeup Jesse. I've been using something similar for a while now. You're script can actually be a single command:

svn up /path/to/site >> /path/to/logfile

Though I haven't done it in practice, I believe that could be sent via key-based (password-less) SSH. (-C maybe?)

3 . Jörn Zaefferer on January 19th, 2008

Jörn Zaefferer

Yep, nice post. Automatic deployment to a development server is definitely worthwhile, though in the project I'm working on its a bit more complicated then just a checkout. Though with the ability to just hook in any script you can think of, it should be easy to eg. run some ant script that builds a war file and deploys it to a tomcat instance.

4 . Pete on February 22nd, 2008


Thanks for this info. Makes subversion much more useful in a hosting environment.

5 . kurapikats on February 29th, 2008


ni post! this is what i've been looking for.
does any body here know how do i do this using a remote svn server?

6 . MegaS on March 25th, 2008


Nice article!
chmod 770 -R * that is what I looked for, thanks:)

7 . Alex on June 9th, 2008


Thank you for the great tips! Subversion rules.

8 . Val on July 13rd, 2008


Hi -Great info here -This may be a silly question, but I can't find where my svn log file is.

svn update >> /path/to/logfile

Can anyone help?


9 . Auto Transport on May 27th, 2010

Auto Transport

Yeah. Is this possible on a remote svn server?

Comments are closed, but I'd still love to hear your thoughts.