Smashing Magazine recently called out a potential security risk with SVN that I think is worth reposting here. This isn't an SVN vulnerability that needs a patch, but rather a symptom of poor deployment practices that are easily avoided. Here's how:
The problem is with exposing the .svn directories to the public through a Web browser. Without proper access security in place, a prying user might be able to obtain your entire site's source code which may contain sensitive information.
There are three common ways to avoid this.
1. Use 'SVN export' instead of 'SVN update' (or checkout) when deploying your code to a production site
This is the safest method as it avoids putting the .svn directories in your web directory in the first place. No .svn directories means no risk. You do however lose many of the benefits of SVN.
For example, if you have a release that deletes files, 'svn export' will not delete anything if run on an existing build, it will only overwrite existing files. In an SVN working copy, 'svn update' will automatically add and delete files in one command.
This method will work fine if you have scheduled releases and can afford to rebuild the entire site directory with every release.
2. Use rsynch to copy your files
Another safe option is to use rsynch to copy all of your files from an SVN working copy to the actual web directory ignoring all the .svn directories. You can use the following option with your rsynch command to do this:
3. Set up your Web server to deny access to your .svn directories
This is simple and just as effective. The Smashing Magazine post gives solid examples to achieve this with Apache.
All three options are safe. Options 1 and 2 pose no risk of exposure with no extra configuration while option 3 requires some minor Web server tweaking. I personally like option 2. It gives you the best of both worlds: no risk and all the great benefits of controlling your code with SVN.