Subversion is a powerful tool. Not only does it allow multiple developers to collaborate on a project, but it allows you to easily deploy your projects to the production server. If you are using a checked out repository on your production server, rather than an exported copy, it is crucial that you protect your hidden .svn directories.
If you do not take measures to protect these hidden folders then your website will become extremely susceptible to attack. Your .svn folders contain the pristine copies of every file with a .base extension. This means that someone with a little know-how can navigate through your .svn folders and download your config files and obtain sensitive information such as your database password. On top of that, they can simply steal all of your code and reproduce your site elsewhere with their name on the bottom.
So how do you protect your site against these attacks? If you have access to the domain’s configuration files you can deny access there by adding the following lines:
<Directory ~ “^\.svnâ€> Deny from all </Directory>
If you are on a shared hosting plan and do not have access to these configuration files, then you can make use of mod_rewrite to block access to the subversion directories. Open up your .htaccess file in your favourite text editor and include the following:
RewriteEngine on # Hide .SVN Folders RewriteRule ^(.*/)*\.svn/ / [F,L]
With these in place your website is now much a safer place.
A seasoned Senior Solutions Architect with 20 years of experience in technology design and implementation. Renowned for innovative solutions and strategic insights, he excels in driving complex projects to success. Outside work, he is a passionate fisherman and fish keeper, specializing in planted tanks.
Have you contemplated doing an svn export (no .svn folders) or having a build script upload everything but the .svn folders to your live directory?
@Daniel: Certainly. Exporting is a fairly new feature (as far as I’m aware) and I have ran several sites as exported repositories problem is when you have to do a quick fix you do it right on the server and its much easier if you can just do a check in and have that quick fix added to the repository.
The problem with “export” is that you can’t do a “delta transfer”; the whole repository has to be copied every time you export. An “update” will almost always be much quicker, because only the change delta needs to be fetched and applied.
This only matches .svn in the root directory. It is likely, that you do not want to publish the svn files in your subdirectory.
@Jan – Yes, as I said this is only for when you’ve checked out a repository rather than exported it.
Thank’s for explaining why you need to block svn directories, other authors don’t do that.
An svn export takes far to long to update and can cause down time depending on the size of your site. svn checkout/update is the preferred way to go.
I find most people have moved to git though so this article is getting a little dated.
@Nick – A lot of people have migrated to git, other old foggies like me have not. There’s still people using CVS, so I don’t think SVN will ever completely die off. But most people will tell you to export not do a checkout for your production, but for the reason you stated plus ease I have always just done a checkout and hidden the .svn directories — it just makes more sense to me.