Deploying software files with subversion

When working with web-based systems, frequently it is a pain to know what version of files you have deployed on a production server. Here is my method of deploying, managing, and updating web-based systems on a production box. It's better than using svn export to update directly from a repository because if used correctly it doesn't require manual copying of unversioned system data to a new checkout, since svn calculates the differences between the tags you switch between.

First, the repository files must be structured correctly. This means that you should have the folders:

/trunk
/tags (or /releases)
/branches

For reference, see the subversion book section on choosing a repository layout.

If on your web server, you've got a directory /project that contains the contents of the repository URL "/releases/release-a" and you want to switch to using the files in the repository release /releases/release-b, all you have to do is use svn switch $REPOS_URL/releases/release-b /path/to/project. Subversion will then calculate the differences between the two release tags and apply them to your working copy. This keeps all nonversioned files intact, leaving you with a deployed system in the same state. You might want to make the appropriate changes to maintain database settings if you're working on an app that accesses mysql.

You may wish to configure the web server to ignore '.svn' directories, if only for paranoia's sake. To do this, you can use the code:

<files ~ "^\.svn">
    Order allow,deny
    Deny from all
</files>

in the appropriate place(s).

When switching, be sure to check for conflicts in the event that someone has made an unexpected change to one of the deployed files (which is not an uncommon occurence in my experience).