We are a web development organization and have recently moved to using subversion for our version control system. Since executing an update is so much faster than doing an export and copying over the files, the developers want to be able to have the production server be a working copy.

The only concern I have with this is all of the .svn files littered across the system, and the fact that some enterprisey individual could, potentially, read the contents of the files in there, possibly giving them information we would rather they did not have.

What is the best/easiest way to prevent IIS from serving up any content from within those .svn directories?

  • 1
    Hello. Could you please clarify what type of information you are concern to have in the .svn that will not be already available in the files deployed?
    – Geo
    Jun 10, 2009 at 13:57
  • What version of IIS? If IIS7 you could get the URL Rewrite Module and just setup a simple rule to ignore .svn directories.
    – MattB
    Jun 10, 2009 at 13:58
  • 1
    @Geo - the .svn directories contains plain-text copies of the files in text-base. Since the files are named the same in there, just with .svn-base appended, people could view the code in plain text (this is a classic ASP site). We'd rather not have that happen.
    – cdeszaq
    Jun 10, 2009 at 15:27
  • @MattB - The server is IIS6 right now, but is switching to IIS7 eventually. So, I will look into the rewrite module for after the switch, but unfortunately, the server is IIS6 right now.
    – cdeszaq
    Jun 10, 2009 at 15:28

7 Answers 7


"Don't do it that way" does not answer the question.

Practically, I like having a working copy on the production server, because that way I can make quick changes in production (who has never done that?) and check them back in. It depends on where you want your security/convenience slider, and in many cases this is a good place.

The standard solution in Apacheland is to leave the .svn files there but tell the web server to never serve them. Here's how to do that with IIS 5-7 on Windows 2000-2008.

  1. Download and install ISAPI_Rewrite -- the Lite version will be enough for this purpose. Note extra system requirements for Win 2008. Warning-- the MSI installer stops and starts IIS.

  2. Uncheck the "read only" box on the httpd.ini file's properties. If you used the MSI installer, therer's a shortcut to the httpd.ini file in the Start menu under Helicon->ISAPI_Rewrite

  3. Add these lines to httpd.ini:

ISAPI_Rewrite directives in httpd.ini:

# Deny access to Subversion working copy administrative
#  directories (.svn) and their contents
RewriteRule .*/\.svn\b.* . [F,I,O]

Now, any request for a .svn directory or its contents will result in a 404 Not Found from the server.

  • I did not notice that I installed the older version, ISAPI_Rewrite2. The newer version, ISAPI_Rewrite3, includes an app called "ISAPI_Rewrite Manager" that makes it a little easier to edit the file, and on Window 2008 Server it did not appear to require restarting IIS. Also, I've posted this with a few more details at my blog: n8v.enteuxis.org/2009/11/…
    – Nathan
    Nov 16, 2009 at 19:44
  • "Don't do it that way" does not answer the question. -- stackoverflow in a nutshell. Thanks for addressing the question directly. Feb 14, 2016 at 17:24

You could make sure that any user accounts used by IIS do not have rights to access the .svn directories.

You can either do this manually (not recommended) or use something like MrJangles delete script either triggered to run after you do the SVN update or run regularly as a scheduled task:

for /r YOURPATH %f in (.svn) do icacls /deny <name_of_iis_user>:F "%f"

(note: I've not tested the above, you'll need to check it does what it is trying to before relying on it in production, see the output of "icacls /help" for more info)

(another note: "icacls" is a Vista/2008 command, on earlier Windows variants the command is "cacls" instead)


Using IIS 7, open IIS Manager, select the server node, double click the Handler Mappings feature. Click the action Add Managed Handler and configure the handler as follows:

  • Request path: *.svn/* (wildcard mapping for all files in all .svn folders)
  • Type: System.Web.HttpForbiddenHandler
  • Name: Subversion-metadata (you can choose a different name if you like)

Now any request for files in the Subversion metadata folders named .svn in alle sites should return this:

Server Error in '/' Application.

This type of page is not served.

Description: The type of page you have requested is not served because it has been explicitly forbidden. Please review the URL below and make sure that it is spelled correctly.

Requested URL: /.svn/text-base/Default.aspx.svn-base

You can choose a different handler type if you want, maybe a FileNotFound handler which will return a 404 status code.

For IIS 6 (with ASP.NET 2 installed and configured):

Navigate to Home directory > Configuration > Mapping and map the .svn-base extension to %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll. Then in machine.config (which you can find in %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\CONFIG) you can add the same handler as above for the extension, add the following XML-element as a child of the <httpHandlers>-element:

<add verb="*" path="*.svn-base" type="System.Web.HttpForbiddenHandler"/>

This will only prevent visitors from requesting the source code files, they could still request other files from the .svn folders. Map more extensions to aspnet_isapi.dll or make a wildcard mapping (will impact performance) and you could block more files from being requested.


From a pure security standpoint, I'd re-educate your developers.

Ease of deployment is not necessarily a good idea if you sacrifice security.

You're planning a configuration to block access to sensitive information. What happens if the configuration accidentally changes. What happens if an IIS hotFix comes down and changes how your config works. What happens if the 3rd party library you use faults out and stops working. I can think of several extremely likely events that would break your config and allow access to these files, which would be TOTALLY MITIGATED by not having the files on the server in the first place.

You should create a deployment script that copies the appropriate files from a staging server. You could even stage via SVN to a different directory on Prod.

To deploy, you can use RoboCopy and the /XD command to exclude .svn directories. You can use the Microsoft web deployment tool and limit the directories with that. You can deploy and run the above for /r YOURPATH %f in (.svn) do rd /s /q "%f" if you need too.

Just don't deploy these directories to production web site.


Don't use subversion. Seriously.

From your comments it appears that you are using the wrong tool for the job. Subversion is a great tool for your developers, but it's not a deployment/mirroring tool. If your goal is to simply copy files from your staging/test server to your production server with a minimum of bandwidth and time, then I suggest you use rsync. Now, since I'm a Unix admin, there may be some Windows equivalent to rsync that I don't know about, so you may want to do some research. However, you can use rsync under Cygwin or cwrsync.

Rsync allows you to mirror directories on one server with directories on another. It calculates a delta between the two servers and only copies the differences. Not only that, but it compresses the delta and, optionally, can encrypt it too.

  • Seconded. The main issue with trying to actively hide the files is that if the handler or rewrite rule you put in place falls down, all of the files are suddenly exposed again. If you have your working copy in a test or private deployment environment and then all you'll need is a big, red 'publish' button (a small script) that rsyncs from that location to the live server. rsync can easily be configured to ignore file paths/patterns and will upload most changes in a heartbeat, and is almost as convenient as your current setup. Nov 18, 2010 at 10:49

Best practice would be an automatic deployment system that exports and publishes after a SVN update is made. Consider Hudson for example. There are few more, but as we do not need one, I'm not very well informed

Greetz, GHad

  • We want to avoid export due to a number of issues, such as bandwidth and connection speed. Update only pull across the things that have changed, which limits the amount of stuff pulled across drastically, which is a major factor for us. Additionally, we don't want things to auto-update, so while Hudson of CC.Net would provide that, it doesn't help us here because we will update production manually.
    – cdeszaq
    Jun 10, 2009 at 15:23
  • if you update manually, why not have your WC in an area not served by the webserver, and copy the updated files from that directory to the directory that is served. You get the benefit of fast network update, at the cost of some disk space.
    – gbjbaanb
    Nov 18, 2010 at 21:56

I schedule a script on my production servers that searches for .svn and simply deletes the files. I don't think this will work in your case.

for /r YOURPATH %f in (.svn) do rd /s /q "%f"

If removing the files isn't an option, you could put basic security on the directories through IIS (password, or IP restrictions). This would stop IIS from serving content to unauthorized users.

Good luck!

  • Removing the .svn directories isn't an option, because we would loose the working copy capabilities. Is there a scriptable way to search through a tree and add those IIS restrictions? The task of doing this manually is too big, and looses the automation that subversion provides.
    – cdeszaq
    Jun 10, 2009 at 15:25
  • No doubt there is. I havent scripted anything like that before, so lets hope someone else responds.
    – Snipper
    Jun 10, 2009 at 15:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .