如何解决“405 Method Not allowed”问题 对于我们的 Subversion 设置？
我们使用在 Windows Server 2003 上运行的 VisualSVN Server 提供源代码。最近，我们将项目的一部分拆分到其自己的存储库中的新项目中，然后使用 svn:externals 将其链接回原始项目。 从那时起，当我们尝试使用 Subclipse 提交文件时，我们一直遇到问题。
我们得到的错误是：
svn：提交失败（详细信息如下）：
svn: PROPFIND of '/svn': 405 不允许方法 (https://svn.ourserver.com)
谷歌搜索了一段时间并没有真正帮助，我们的配置似乎是正确的。 还应该指出的是，我们已经运行该服务器一段时间了，没有出现这些问题，并且除了将项目拆分为两个存储库之外，没有对服务器进行任何更改（即配置文件相同）。
还应该注意的是，这些错误仅在我们尝试一次签入多个文件时才会出现。 如果我们一次签入一个文件，就不会出现错误。 此外，据我们目前所知，它仅出现在 Subclipse 中，而 Versions.app (OS X) 似乎工作正常，所以这是我们当前的解决方法。
如何分析错误以找出原因并随后修复？
我绝不是 SVN 大师，现在我一无所知。
看来我们可以签入同一个包中的多个文件，但不能签入多个包中的文件。 此外，当我将项目“拆分”为两个存储库时，我使用新名称导入了原始存储库。 我没有进行转储然后导入该转储。 这可能是我们问题的根源吗？如果是，我该如何解决？
经过一番思考后，似乎它确实与在不同存储库中签入文件时有关。 如果我尝试同时在存储库 A 和存储库 B（由 svn:externals 引用）中进行一次提交，则会收到错误。 Versions.app 正确处理了这个问题，但我猜它可能只是做了两次提交，而不是一次提交。 Subclipse 惨遭失败。 现在，我们只需进行多次提交，一次提交给存储库 A，一次提交给存储库 B，效果就很好。 如果比我聪明的人可以详细说明为什么会发生这种情况，这种设置是否愚蠢等等，请继续。
We're serving our source code using VisualSVN Server running on Windows Server 2003. Recently, we split a portion of a project into a new project in its own repository, and then linked it back to the original project using svn:externals. Since then, we've been having issues when we try to commit files with Subclipse.
The error we're getting is:
svn: Commit failed (details follow):
svn: PROPFIND of '/svn': 405 Method Not Allowed (https://svn.ourserver.com)
Googling for a while didn't really help, and our configuration seems to be correct. It should also be noted that we've been running this server for a while now without these problems and apart from splitting the project into two repositories, no changes have been made to the server (i.e., configuration files are the same).
It should also be noted that these errors only appear when we try to check in multiple files at once. If we check in one file at a time there are no errors. Also, it only appears in Subclipse as far as we know right now, and Versions.app (OS X) seems to work fine, so that is our current workaround.
How do I analyze the error to find the cause and subsequently fix it?
I'm by no means an SVN guru and right now I'm clueless.
It seems we can check in multiple files in the same package, but not files from multiple packages. Also, when I "split" the project into two repositories, I imported the original repository with a new name. I did not do a dump and then import that dump. Could that be the source of our issues, and if so, how would I solve that?
After some jerking around it seems as though it is indeed related to when checking in files in different repositories. If I try to do a single commit in both repository A and repository B (referenced by svn:externals) at the same time, I get the error. Versions.app handles this correctly, but I guess it might just be doing two commits, not a single one. Subclipse fails miserably. For now, we simply do multiple commits, one for repository A and one for repository B, that works just fine. If anyone smarter than me could fill in the details why this is happening, whether or not this kind of setup is stupid, etc., please go right ahead.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
先决条件：雇用一名优秀的管理员
问题：VisualSVN Server 对其中存储库的所有和任何部分使用基于路径的身份验证。 默认访问级别 (AFAICR) - 根目录为
* = r，此设置继承到下面的所有节点（存储库的根目录也是如此），并且当您尝试提交到新存储库时没有良好的 ACL 对于它（或配置错误），您遇到问题解决方案：在 VisualSVN Server MMC 小程序中检查新存储库的属性，并检查权限和用户。 在最简单的情况下，在超级存储库（具有外部的存储库）中具有写入权限（可以提交）的用户必须在子存储库（具有链接的存储库）中具有（如果策略允许）写入权限。资源）。
Prerequisite: Hire a good administrator
Problem: VisualSVN Server uses path-based authentication for all and any parts of repos inside it. Default access-level (AFAICR) - is
* = rfor root and this setting inherited into all nodes below (repository's root also) and when you try to commit into a new repository without good ACLs for it (or misconfigured) you get a problemSolution: Check Property of the new repository in the VisualSVN Server MMC-applet, and check permissions and users. In the simplest case, the user, who have write-rights (can commit) in a super-repository (repository with externals) have to have (if it is allowed by policy) write-rights in the sub-repository (repository with linked resources).