Cons of checking out files from trunk to live servers?

Question

I was going through http://stackoverflow.com/questions/263782/what-is-the-best-way-to-make-files-live-using-subversion-on-a-production-server If I run a hook that will checkout all the files updated in trunk to the online servers, .svn folder gets created. Are there any cons to this?

OR Do I actually need to use 'export' rather than 'check out'?

Answer 1

Make sure your .svn folder is not available from the web browser. Code source lives in there, often including things like database passwords.

One advantage of checking it out is that if you log into the server and fix something there, you can commit your change back to the repo without mirroring it on your own machine.

Answer 2

This is one of the reasons why GIT is better than SVN, all those svn folders on a live site? not a great idea.

Answer 3

I would use "export" instead of checking out as a means of deployment. This does the file pulls but doesn't create all those .svn you dont need in your war, jar, or whatever.

Answer 4

We are successfully using svn working copies for php sites on live and test servers. Do make sure you have a rule in your Apache config to prevent .svn folders being viewed - a quick google search reveals lots of careless people who haven't.

Things we found/considered:

• you don't need expose your svn server - do updates by connecting to the target server with ssh and opening a tunnel from the target server back to your svn server
• on the target server, use an svn username/password which has read-only access, preferably just to the project in question
• it allows you to do patches on test/live servers (if you really really have to) and be able to keep track of them, and revert them easily
• on any directories which the web server needs write access to, add the 'svn:ignore *' property, plus a custom property (eg. 'my:dir_type = upload')
• use that custom property in a script which runs after any svn updates, which will set the permissions on those directories as required
• if you use tags, you can switch the working copy to a new tag with the 'switch' command
• only the changes are copied - this is great for a large app, saves many hours of uploading files