Ftp – Copy files from SVN server to external server via FTP

"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.

This is because SVN uses a local 'cache' of the working copy files to decide what is different from the repository (so it doesn't have to contact the repo, to fetch the file, to diff it, just to find out that you've changed it).

In this case, that isn't working as you want as the working copy (and its cache) is out of sync with the repo. When you change those file and commit them, then you'll find that SVN will re-sync itself (and throw a 'whats going on' error no doubt).

So, you need to re-sync the working copy cache manually. First, take a copy of the working copy directory without the cache - ie the .svn directories. (search for .svn using the old Windows Search doggie and delete all those directories)

Then update the directory to fetch the current status of the repo, I think SVN will update the cache and will merge your local changes to the files in the repo, so you will be back to normal - ie the changed files will get the 'modified' icon, and then you can commit the changes. I'm pretty sure this is what will happen, but I'm always paranoid about losing data after a restore which is why you will first make the copy. If anything goes wrong, you can just overwrite the files fetched from the repo with your old WC, and it'll show as modified. commit as normal.