Reasons for/against using svn for deployment?

Question

So,

At my job we use svn to manage our source code, but when deploying, we do an svn export and rsync that tree with the code that is on production. This is the way it has been done since I started (it is my first programming job) and how we continue to do things.

I've started to work on my own personal projects outside of work and still use svn to to manage my code - however, instead of syncing an export with the tree on the server, I simply do a checkout on the server and when I roll new code I just svn up. This seems simpler to me.

Are there good reasons not to use svn on a production machine? A security risk that I'm overlooking?

Answer 1

I can think of a couple of issues:

• checkout on the server will create unecessary .svn directories there
• to checkout on the server, the user needs both SVN and server access rights

These are off the top of my head - I'm sure there are more.

Answer 2

A svn checkout is ~2x the size of the exported data, because the .svn folders contain data used to revert in case you make a mistake. Exporting doesn't create the .svn folders, and therefore can use less space.

Answer 3

I think Svn for deployment is ok. It's easy if your server has the client installed, and it has less steps than export and rsync.

The only problems I can see is some cheap hosting providers who don't support that, and that the svn client may store the account you used to check out the code, possibly allowing someone else access.

Answer 4

• extra load on the server
• changes to your prod environment imply disruption to what should be unrelated aspects of your dev infrastructure, and vice versa. Problems with one disrupts the other.
• challenges managing roles and permissions. Neil's example of needing both svn and server accounts is one example. Managing appropriate file system access controls is another (should the whole team have write permission to the production directories?).

In a nutshell, using svn on the server introduces a tighter coupling between dev and prod, which causes issues that aren't so different from tight coupling between different parts of code.

Answer 5

1st thought: In the event of compromise, your attacker now has access to your source code as well.

Answer 6

You'll be making your source code available on the web in the .svn directories, which might be a problem.

This is exactly what we do with phc, and you can access the .svn files as a result. But since its open-source, that doesn't matter.

You could fix that with .htaccess files, of course.

Answer 7

If you dont want to have .svn folders in your www live directory and still use update instead of export because it's faste, just checkout your www repository in a different folder called for example predeployfolder.

Every time you want to transfer the current HEAD repository version to your live www folder, do a quick svn update in the predeployfolder and after that do resync between the predeployfolder and your live www folder and specify that the .svn files have to be ecluded like that:

rsync -az --eclude="*.svn*" predeployfolder wwwlivefolder