2010-11-03 51 views
2

我有一个Windows托管的mercurial存储库,UserA,UserB和UserC有权推送到。 UserA可以高兴地推/拉等...但一旦UserC推送... UserA开始收到以下错误:用户推送到mercurial存储库导致其他用户的http 500错误

abort:HTTP错误500:.hg \ store \ data/_web/_mvc._sitemap.i:访问被拒绝

唯一的'修复'是为了核实和重新启动远程存储库。

有没有人有这种类型的问题的经验?

更新: 存储库位于服务器上的驱动器上,IIS位于其上。用户在本地连接。安装程序非常适合Mercurial wiki。

+0

提供有关mercurial服务器的更多详细信息。它是如何设置的。用户如何访问它... – pyfunc 2010-11-03 17:24:18

+0

为了清晰起见,我更新了问题。 – Webjedi 2010-11-03 17:29:07

+1

这是一个权限问题,当C推送他添加的文件没有正确的权限时,这意味着Web服务器无法访问它们。 – tonfa 2010-11-03 17:59:55

回答

2

我把tonfa的答案放在这里,附加一些额外的信息。这是完全正常的,实际上文件系统是如何工作的。当你的用户直接用磁盘访问时,他们正在创建他们拥有的新文件。除非采取措施确保其拥有的文件也可由其协作者写入,否则后续推动者(以及依赖于默认权限的拉手)将被告知他们无法访问新创建的文件。

有几种常规方法来避免这种所有这些都是服务器管理员的工作而不是推送用户的工作。或者:

  • 更改权限,以便所有的新文件会自动与权限,让所有合作者读/写访问
  • 让每个人只能使用HTTP接口,用于推/拉使所有的读/写操作的完成添加相同的(IIS)用户

在unix土地前者很容易做到使用“粘性组”位和“umask”。在Windows上,可能只有一半的时间更简单。 ;)

+0

每个人都在使用HTTP接口,所以很奇怪,为什么它看起来不太好。我所做的和似乎正在工作的是将.hg和子文件夹的所有者更改为服务器的用户组。非常感谢......会发誓要通过HTTP和单个IIS用户本来可以,但显然不是。 – Webjedi 2010-11-04 14:32:50

+0

这是一个模糊的回忆,但我认为Mercurial使用.hg/store目录本身的权限作为它创建的任何新文件的权限(与* nix上的umask的反和),所以如果.hg/store最初创建瓦特/非群体友好烫发可能有所作为。这可能会解释你纠正.hg子文件夹的问题。无论如何,很高兴现在去为你好。 – 2010-11-04 15:34:39

相关问题