SVN checkout or export for production environment?

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

IMHO you should create a branch/tag where you have the (desired) subset of the dev env which you use for production. Someone should either maintain this manually or automatically using scripts. Then, you should export (rather than checkout). Incremental updates are a non-issue, unless you're changing files on your production environment and you don't want those files to be overwritten.

Just my $0.02

Answer 2

I would look into some deployment software like Capistrano (it's a ruby program)

I would personally use exporting a tagged copy of trunk instead of just exporting trunk if you are going to use be rolling your own solution or manually.

Answer 3

No question - export.

You would not be making updates, so no reason to have a checkout. You would just be deploying junk out.

I would say any environment should be only an export; you only use checkout locally when you are developing. Of course we are also using build scripts, so updating the deployment is as simple as running the script.

As far as the in development code, create branches for any work being done. Only commit to the trunk when ready for deployment to the development environment.

Answer 4

I deploy it as a copy. Not manual, of course.

I use 'make' and 'checkinstall'. I create a small Makefile which uses the system command 'install' to copy all the needed files to the appropriate directories on the web server, and I have preinstall and postinstall shell scripts that will be run on the server.

When time for deployment comes, I just run 'checkinstall' which creates a package (RPM, DEB or TGZ, depending on which Linux distribution I target). I install it using regular tools provided by a Linux distribution package manager (rpm, dpkg, pkgtool). Of course, if you want to track dependencies as well, you can use yum, apt-get, etc.

It makes it really easy if you want to distribute a new version of your web app. to multiple target servers. And stuff like uninstall, reverting to an older version, etc. are very easy because you have a ready to use package for each version you deployed.

This might not fit your 'push often' strategy though if you use some stuff that needs compiling. However, for scripting stuff (like PHP that I do), creating a package (of about 300+ PHP files) takes about 20 seconds on my machine. And about as much to install it on any target system.

To separate the code 'for release' from the 'in-development' code, I use branching. With Git, it's really easy, since branching is cheap and fast.

Answer 5

I've been struggling with this, and I think I finally decided on checkout. Yes, there is extra junk there, but...

• Export doesn't account for deleted files (unless your solution is to delete everything in the dir and THEN export, which I think is way worse). Checkout will remove deleted files.
• Checkout is faster. Period. Fewer files being updated means less down/transition time, and an export pulls down and overwrites EVERYTHING, not just files needing an update.

Not saying it'll work for everyone, but these two things influenced my decision. Best of luck with your decision.

Answer 6

EXPORT

that's it. You don't have any good reason to put extra junk into production system.

• You'll expose your source code
• If this is web application it's even worse, your visitors can download your source code, how cool is that! very open :)

Answer 7

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.

Answer 8

Personally I'm always in doubt about the solution of this problem, I prefer having no ".svn" directories around my production environment, it's very dirty but at the same time, export is very tedious with large web applications (especially if using some 3rd parties "components" like Extjs,FCKeditor etc..).

I think there are not "killer solutions" at this moment.

Answer 9

let me see..... ln -s ? what can that be used for?

/var/www/www.my-prod-site.com/public/
/var/www/www.my-prod-site.com/builds/Rev 1/
/var/www/www.my-prod-site.com/builds/Rev 2/
/var/www/www.my-prod-site.com/builds/Rev 3/
/var/www/www.my-prod-site.com/builds/Rev 99/

svn export to your builds directorys...... copy any config files over from /public that is your symbolic link to your former release build, and then just shift the symbolic link from public to point to your new build directory. it takes less time offline than any of the things i have seen posted here, and it also makes going back WAY FASTER unless you f*ck*p your db everytime by altering tables.