Question: There is a known issue with SVN repositories and the windows indexing service fighting over .svn metadata files. [Here for more details.](http://schleichermann.wordpress.com/2009/12/09/svn-tortoisesvn-cant-move-the-file-or-directory-is-corrupted-and-unreadable-windows-7/)

How can we set it up so there are **automatically** no problems having subversion repositories indexed by windows (Vista/Win7). *(We don't want to have to manually do something every time we add repo directory.)*

One idea is to setup Windows to automatically not index folders named ".svn", however I can not find a way to do this.

I know you can disable certain extensions, but that doesn't seem to work since the svn metadata files are in a folder.

Note: The

Answer: 
I was having the same problem and found a solution. All my code is stored under a single folder: 

F:\projects\ 

Under that folder are trees of code and related project files that total over 2GB. I constantly need to search this tree and windows Indexing has actually been an extremely useful tool for doing fast searches, so turning it off was not an option. I want to exclude the SVN folders because they clutter up my search results, (2) unnecessary drag on my system, (3) SVN, Win7, and MS Security Essentials seem to not work nicely when doing large SVN operations. 

**Before you try the solution, reproduce the problem:** 

1. In Windows Explorer, navigate to your indexed project root (F:\projects\ on my machine).
2. Using the Search bar in the upper-right corner of the Explorer window, search for "svn" (w/o quotes)
3. You should see a trillion useless SVN files & folders like ".svn", and "svn-base" showing up in the results.

**Solution:** 

1. Visit <http://code.msdn.microsoft.com/windowssearch/>
2. Download CrawlScopeCommandLine.zip
3. Extract to some place on your machine, and compile the project
4. Open a Console window with administrative rights (Ctrl+Shift+Left-click on the "Command Prompt" item in the Start menu).
5. Navigate to wherever you compiled the above project to.
6. Execute the csmcmd.exe with the /add\_rule param (use /? first for syntax).
7. In my case I entered the following command: 
`csmcmd.exe /add_rule file:///F:\projects\*\.svn\* /USER /EXCLUDE`

I figured this out by first running the command: `csmcmd.exe /enumerate_rules`, to list all the existing ones. There were already some rules with asterix (\*) wildcard's being used by Windows, so it was proof this was possible. 

Now repeat the steps to reproduce the issue, and you should no longer see the SVN clutter in your search results. Give the computer sometime to update the indexes -- this took less than 5 minutes on my system. Sometimes restarting the Search service, kicking off a rebuild/reindex, or a reboot help move things along.

**Update**: Some of my SVN projects use ".svn", and some use "\_svn", so I've added these two rules to every drive: 

`csmcmd.exe /add_rule file:///F:\*\.svn\* /DEFAULT /EXCLUDE`
`csmcmd.exe /add_rule file:///F:\*\_svn\* /DEFAULT /EXCLUDE`
The obvious fix would be to change Subversion to set this "don't index" flag whenever it creates a .svn directory. The problem is that this feature will be no longer needed when it's introduced.

The known problem will most likely go away in the Subversion versions that's currently being developed (version 1.7). There will be far less file operations inside the .svn directory, and also just 1 .svn directory per working copy.

This makes it less likely that the problem will occur, and also makes it far easier to disable indexing, because there's just a single .svn folder.