Question

In a project I am working on, we have an ongoing discussion amongst the dev team – should the production environment be deployed as a checkout from the SVN repository or as an export?

The development environment is obviously a checkout, since it is constantly updated.
For the production, I’m personally for checking out the main trunk, since it makes future updates easier (just run svn update). However some of the devs are against it, as svn creates files with the group/owner and permissions of the svn process (this is on a linux OS, so those things matter), and also having the .svn directories on the production seem to them to be somewhat dirty.

Also, if it is a checkout – how do you push individual features to the production without including in-development code? do you use tags or branch out for each feature? any alternatives?

EDIT: I might not have been clear – one of the requirement is to be able to constantly be able to push fixes to the production environment. We want to avoid a complete build (which takes much longer than a simple update) just for pushing critical fixes.

Answer 1

The Subversion FAQ seems to advocate deployment as a checkout, autoupdated with post-commit hook scripts. They prevent Apache from exporting .svn folders (probably a good idea) by adding the following in httpd.conf:

# Disallow browsing of Subversion working copy administrative dirs.
<DirectoryMatch "^/.*/\.svn/">
    Order deny,allow
    Deny from all
</DirectoryMatch>

I’m extremely new to svn myself, but maybe you could trigger a hook script when you create a new tag. That way, when you’re ready to update the live site, you just commit your last changes to the trunk, create the new tag, and the script updates your live site with svn update.