Are there any disadvantages to using a working copy for your live website with SVN 1.7?

Question

I'm planning to publish our live site today and I've read that the best option is to use svn export to avoid populating the working copy with .svn files, however this is no longer an issue with SVN 1.7 as the metadata is stored in a single file. Seems to me that using a working copy is much better than exporting as updating the live site would be as simple as running 'svn update'. Is there any reason not to checkout a working copy and use export?

Answer 1

The problem with using svn update is that it's too easy to update your live site. You might update to a version that doesn't work or is untested.

I'd recommend instead a hybrid approach - before releasing a new version, tag it, then svn switch the live site to that tag.

Obviously you still need to ensure you aren't serving up the root .svn directory.

Answer 2

Situation you're describing is a serious security threat.

As you might already know, Subversion stores its metafiles directly in working copy using .svn folders. Each such folder has file entries with the list of all directories having the same level as the corresponding .svn folder. In .svn folders you can also find information about repository location, filesizes, modification dates and user logins. In the case you're deploying your site simply by checking out working copy to the htdocs directory on the web-server, then using URL site.com/.svn/entries you will see not only project filestructure, but also list of authors, latest changes, link to the repository, etc.

You can also find text-base directory in each .svn folder. It contains latest revision of all files placed under version control. Files in text-base directory have .svn-base extension, it allows to send its content directly to the browser output without interpreting it on the server side. Namely, it allows to see raw source code!

Nevertheless, there are simple solutions to this problem.

Apache:

<Directory ~ ".*\.svn">
    Order allow,deny
    Deny from all
    Satisfy All
</Directory>

Nginx:

location ~ /.svn/ {
    deny all;
}

To sum up, main disadvantage of such approach is that you should know about the threat and do not forget to prevent possibility of accessing .svn directories from web.