我不是系统管理员,但显然我必须在电视上扮演一个系统管理员。不过,我确实说服了我的工作场所开始使用版本控制,因此我成为了管理它的人。问题是我必须在他们现有的系统上执行此操作。因此,我在 32 位的 Windows Server 2003 Web 版上运行 Visual SVN。我没有对任何东西进行任何改动,因为我不知道自己在做什么。这是我们的开发 Web 服务器,我刚刚在其上进行了 VisualSVN 的标准安装。存储库托管在这台机器上,客户端工作副本位于指向同一台机器上某个位置的映射网络驱动器上。
使用 32 位 Windows 7 的用户在使用 Tortoise 或 Smart SVN 客户端时没有遇到任何问题。但是,我的 64 位用户会定期遇到
“服务器拒绝连接 OPTIONS 请求失败”
消息并且无法连接到 SVN 服务器,这种情况会一直持续到他们重新启动计算机,并且上述两个客户端都会发生这种情况。值得一提的是,有一个适用于 Smart SVN 的小型 64 位补丁,用于处理 shell 集成,并且已应用。
那么这条消息是什么意思,我该如何解决它?请记住,虽然我作为计算机用户经验丰富,但在管理计算机方面我却力不从心,因此请您原谅我。还请注意,如果有在 Linux 机器上运行 SVN 的选项,那么它早就完成了。我别无选择,只能在这种环境中工作。
编辑 2012/3/15
我让一个用户再次遇到这个问题,并按照 Lazy Badger 的建议跑过去并使用 slikSVN 尝试更新。CLI 也出现了错误,但措辞略有不同:
“svn:选项”http://[我们的服务器]:8080 / svn / [repo] / trunk / [toplevelfolder]':无法连接到服务器(http://[我们的服务器]:8080)”
编辑 2012/3/19
我找到了一个可能的解决方法。今天我又遇到了这个错误。为了检查网络是否正常,我让他在他的网络浏览器中浏览 repo,只需转到“http://[我们的服务器]:8080/svn' 并登录。这似乎允许他的 SVN 客户端再次访问服务器,而不会出现错误,也不会中断重启。如果此解决方法再次成功,将再次更新。
答案1
你确定是 32 位或 64 位 Windows 出了问题吗?除非你的 64 位 svn 客户端版本有特定的错误,否则我怀疑这里的位不是问题。
出现此错误的原因之一是 OPTIONS HTTP 方法被防火墙或 svn 服务器本身过滤。请关闭可能在用户的 Windows 计算机上运行的防火墙(安全性较低)(或者,更安全的做法是专门允许此类流量)。
如果用户收到“OPTIONS 请求失败”消息,您是否能够获取“svn 状态”,您是否能够访问 svn 服务器?svn 客户端应该有办法获取状态。
答案2
当您说“visualSVN”时,您的意思是“VisualSVN Server”,对吗?!
- “OPTIONS 请求失败”不是与客户端(和客户端架构)完全无关 - 这是纯粹的服务器端错误
- 没有 Apache 的日志,我们什么都做不了
- VisualSVN Server 中的日志记录已完全禁用,您必须在 httpd.conf 中手动启用它
- 对于测试,我建议使用 CLI svn-clients - 如果出现错误,它们会报告更多详细信息(64 位 SVN CLI 客户端SlikSVN,32位可以用任意)
顺便说一下,旁注
客户端的工作副本位于映射网络上
是非常非常糟糕的想法
更新
澄清和细节
您可以链接或包含有关编辑第 3 点中提到的日志的说明吗?
VisualSVN 服务器标准版有
ErrorLog nul
LogLevel error
在 Apache 配置中,因此 - 在事件日志中几乎没有记录任何内容(在单独的部分中)。 访问和操作日志记录(事件日志)只能在企业版中从 GUI 中的框中启用。您可以通过定义常用的 ErrorLog&AccessLog 来启用标准日志记录,并在扩展版本中查看操作和错误,与前端 (原因为“OPTIONS 请求失败”)。但是SVN 书籍还有关于Apache 额外日志记录在 CustomLog 中,允许将 WebDAV 命令“翻译”为 SVN 命令
请解释一下为什么将工作副本放在映射网络驱动器上是一个坏主意?
- Visual Studio + svn:工作副本在网络驱动器还是本地?主题在这里
- 回答TortoiseSVN 常见问题解答
- SVN 网络共享工作副本话题
- 稍微过时的警告关于 BDB-repo(无论如何都要使用 FSFS)“不要在网络共享上创建或访问 Berkeley DB 存储库。它不能存在于远程文件系统上。即使您将网络驱动器映射到驱动器号也不行。如果您尝试在网络共享上使用 Berkeley DB,结果将不可预测 - 您可能会立即看到神秘的错误,或者可能要几个月后才会发现您的存储库数据库已被巧妙地损坏”
我们需要将其放在 Web 服务器上,以便处理服务器端语言
什么?!每个开发人员一个服务器还是所有开发人员共享一个副本?你(或经理或……)有重新思考关于实施 VCS 后的工作流程 - 您不能使用公共堆与以前一样,只是在顶部进行了版本控制。这个帖子将(可能)有助于理解我的反应,Subversion FAQ 中的这个答案将有助于构建更新的工作流程。提交后钩子解决方案有一些尖角(并行操作),但如果它成为问题,你可以转向生产质量的 Build-CI-Deploy 工具