title: AnkhSVN breaks ASP.NET sharing permissions with SVN 1.7
body: <p><strong>The Background</strong> (skip to the bottom if you want the question)</p>
  
  <p>Recently I upgraded an SVN repository (hosted on assembla) to SVN 1.7. After doing so, we started to intermittently encounter lots of <code>File Access Denied</code> errors on the ASP.NET site pages that sit in the local working copy of the repository.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p><strong>My Environment</strong></p>
  
  <ul>
  <li>Visual Studio 2010 Ultimate 10.0.40219.1 SP1</li>
  <li>AnkhSVN 2.3.10509 (latest version, supports SVN 1.7.1)</li>
  <li>TortoiseSVN 1.7.1, Build 22161 - 64 Bit</li>
  <li>Running in Debug Mode via the Azure emulator environment</li>
  </ul>
  
  <p><strong>The Question</strong></p>
  
  <p>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?</p>
  
  <hr>
  
  <p>The exact file permission error dumped out is this:</p>
  
  <blockquote>
    <p>Access to the path '//file//' is denied.</p>
    
    <p>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.</p>
    
    <p>Exception Details: System.UnauthorizedAccessException: Access to the
    path '//file//' is denied.</p>
    
    <p>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.</p>
    
    <p>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.</p>
  </blockquote>
  
  <p>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.</p>