SVN is definitely cool. So I use it for quite all of my projects. Being able to jump back, having a versioned backup, share-coding with others – awesome.

But most of my projects are to run on some kind of webserver. Usually I use my local webserver to test, so I can symlink directly into the projects (and then upload to productive manually). That’s okay for me. But for a recent project I have to test on some remote ftp. So shall I each time commit/update then upload to FTP? And all other team members too? Come on, we are humans, that is stupid repetitive computer work!

So I discovered SVN hooks. These are kind of scripts that can be called each time a SVN repository is changed. Find the directory in path/to/repos/hooks. I found this for my FTP hook: svn2web – it’ll give you all you need to setup the hook. The real cool thing is that you can define the ftp/sftp-behaviour in SVN properties:

svn propset svn2web "sftp:username:password@machine:/path" .

My pre-commit hook looks like this:

#!/bin/bash
export PATH=/usr/local/bin:/usr/bin:/bin
svn2web $1 $2 >> /tmp/svn2web.log || exit 1
exit 0

Be aware of two things:

1. Install svn2web commands in /usr/local/bin – now you have to export the path variables in the hook script, because it will be called without any path variables (for security reasons)
2. If the ftp upload fails for whatever reason, the commmit will fail too. That’s what we want, usually, because otherwise we wouldn’t get any feedback on comitting. If you don’t want, just setup the hook as post-commit.

For some reasons my ftp-upload hook wouldn’t work on this stupid test server. I spent quite some time figuring out why and what. It seemed that whenever ftp tried to PUT, the ftp server tried to change to some extended passive mode and would hang there. I found out that when calling the command

epsv

before ftp operations, this wouldn’t happen. So, cool :-)

I like to keep all my projects on a svn server. So far this was just for myself and I didn’t care much about the simplicity of checking out and in – a little chaos is acceptable if you’re up to handle it ;)

Finally I was forced to rethink this strategy because I wanted to let other people work on a project. As many actionscript projects, this one also heavily relies on external libraries, most of them hosted by Google Code, another one being my own (closed) lib. So should I tell people: «hey, just svn checkout from here and there and then relink the libs in the project properties but don’t check in the updated settings for christ’s sake!»No. Too shaky, really.

Fortunately, SVN provides a fucking cool way to solve this issue: svn:externals. (more…)