asp.net - AnkhSVN 打破 ASP.NET 与 SVN 1.7 共享权限

Question

背景 (想提问请跳到底部)

最近我将一个 SVN 存储库(托管在汇编上)升级到 SVN 1.7。这样做之后，我们开始间歇性地遇到很多 File Access Denied位于存储库本地工作副本中的 ASP.NET 站点页面上的错误。

一些文件夹也开始获得奇怪的文件权限(它们被标记为只读)并且用户共享被从中删除。这些问题只会在更新/提交周期后通过 AnkhSVN 的 Visual Studio 插件开始发生，但不会一直发生；它似乎非常喜怒无常。

到目前为止，我们发现的唯一临时修复是提交任何未完成的更改，删除本地副本并重新 checkout 完整的工作副本(使用 TortoiseSVN)。但是，这不是一个可行的修复方法，并且会严重影响生产力。

此站点是基于 Azure 的 ASP.NET WebWorkerRole。在升级到 SVN 1.7 之前，它从未出现过问题。我尝试摆弄内部 IIS 权限来解决这个问题，但是，没有骰子。

我的环境

Visual Studio 2010 Ultimate 10.0.40219.1 SP1

AnkhSVN 2.3.10509(最新版本，支持SVN 1.7.1)

TortoiseSVN 1.7.1，内部版本 22161 - 64 位

通过 Azure 模拟器环境在 Debug模式下运行

问题

SVN 1.7 或我环境中的任何工具是否有可能破坏文件权限，从而使文件在 ASP.NET 站点中无法使用？更重要的是，我该如何解决这个问题？

转储的确切文件权限错误是这样的:

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.

但是干净的工作副本不会产生这个错误。比较两者的权限，似乎没有窃听的工作副本是共享的(与IUSR和本地帐户)，而损坏的工作副本为零共享，但用户永远不会更改共享。

Answer 1

当 subversion 更新文件时，它首先在 .svn/tmp/中创建一个临时版本。然后它将文件移动到正确的位置。 (这是为了避免腐败)

在 1.6 中，它自己为每个目录执行此操作，但在 1.7 中，您的工作副本的顶级目录中只有一个 .svn。

如果此 .svn 目录的文件系统权限以某种方式受到限制，则在将文件移动到位时，这些限制可能会随文件一起复制。
(Subversion 不会更改 Windows 上的权限本身)