visual studio 2010 - AnkhSVN breaks ASP.NET sharing permissions with SVN 1.7

Question

The Background (skip to the bottom if you want the question)

Recently I upgraded an SVN repository (hosted on assembla) to SVN 1.7. After doing so, we started to intermittently encounter lots of File Access Denied errors on the ASP.NET site pages that sit in the local working copy of the repository.

Some folders also started to get weird file permissions (they became marked read-only) and user sharing got removed from them. These problems would only start occurring after an update/commit cycle, via AnkhSVN's Visual Studio plugin, but not all the time; it seemed highly temperamental.

The only temp-fix we've found so far is to commit any outstanding changes, delete the local copy and re-checkout a full working copy (with TortoiseSVN). However, that is not a viable fix, and it is seriously impacting on productivity.

This site is an Azure based ASP.NET WebWorkerRole. It has never given problems before the upgrade to SVN 1.7. I tried fiddling with the internal IIS permissions to get around the problem, however, no dice.

My Environment

• Visual Studio 2010 Ultimate 10.0.40219.1 SP1
• AnkhSVN 2.3.10509 (latest version, supports SVN 1.7.1)
• TortoiseSVN 1.7.1, Build 22161 - 64 Bit
• Running in Debug Mode via the Azure emulator environment

The Question

Is it possible for SVN 1.7 or any of the tools in my environment to break file permissions so that the files become unusable in an ASP.NET site? and more importantly, how do I fix this?

---

The exact file permission error dumped out is this:

Access to the path '//file//' is denied.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.UnauthorizedAccessException: Access to the path '//file//' is denied.

ASP.NET is not authorized to access the requested resource. Consider granting access rights to the resource to the ASP.NET request identity. ASP.NET has a base process identity (typically {MACHINE}ASPNET on IIS 5 or Network Service on IIS 6 and IIS 7, and the configured application pool identity on IIS 7.5) that is used if the application is not impersonating. If the application is impersonating via , the identity will be the anonymous user (typically IUSR_MACHINENAME) or the authenticated request user.

To grant ASP.NET access to a file, right-click the file in Explorer, choose "Properties" and select the Security tab. Click "Add" to add the appropriate user or group. Highlight the ASP.NET account, and check the boxes for the desired access.

But a clean working copy will not generate this error. Comparing the permissions of the two, it seems the working copies that are not bugged are shared (with IUSR and the local account), whereas the broken ones have zero sharing, yet the sharing is never changed by the user.

Answer 1

When subversion updates a file it first creates a temporary version in .svn/tmp/. It then moves the file into the right location. (This to avoid corruptions)

In 1.6 it did this for every directory by itself, but in 1.7 there is just a .svn in the top level directory of your working copy.

If somehow the filesystem permissions of this .svn directory are restricted, it is possible that the restrictions are copied with the file when it is moved in place. (Subversion doesn't change the permissions itself on Windows)