用户推送到 Mercurial 存储库会导致其他用户出现 http 500 错误
我有一个 Windows 托管的 Mercurial 存储库，UserA、UserB 和 UserC 有权推送到该存储库。 UserA 可以愉快地推/拉等...但是一旦 UserC 推...UserA 开始收到以下错误：
abort: HTTP Error 500: .hg\store\data/_web/_mvc._sitemap.i: 访问被
拒绝对此的唯一“修复”是对远程存储库进行核攻击并重新初始化。
有人对此类问题有经验吗？
更新： 存储库位于服务器的驱动器上，IIS 位于其顶部。用户在本地连接。设置与 Mercurial wiki 非常一致。
I have a windows hosted mercurial repository that UserA, UserB and UserC have rights to push to. UserA can happily push/pull etc...but once UserC pushes...UserA starts to receive the following error:
abort: HTTP Error 500: .hg\store\data/_web/_mvc._sitemap.i: Access is denied
The only 'fix' for this is to nuke and re init the remote repository.
Does anyone have any experience with this type of issue?
Update:
Repository is sitting on a drive on the server with IIS sitting on top of it. Users connect locally. Setup is pretty much right of the Mercurial wiki.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我将 tonfa 的答案和一些额外的信息放在这里。这是完全正常的，也是文件系统的工作原理。当您的用户使用直接磁盘访问进行推送时，他们正在创建自己拥有的新文件。除非采取措施确保他们拥有的这些文件也可由其协作者写入，否则后续的推送者（以及拉取者，取决于您的默认权限）将被告知他们无法访问新创建的文件。
有一些通用方法可以避免这种情况，所有这些都是服务器管理员的工作，而不是推送用户的工作。要么：
在 unix 环境中 完成前者很容易使用“粘性组位”和“umask”来完成。在 Windows 上可能有一种更简单的方法，但效果只有一半。 ;)
I'm putting tonfa's answer down here with a little extra info. This is completely normal, and really just how file systems work. When your users are pushing with direct disk access they're creating new files that are owned by them. Unless steps are taken to make sure those files owned by them are also writeable by their collaborators then subsequent pushers (and pullers depending on your default permissions) will be told they can't access the newly created files.
There are a few general ways to avoid this all of which are the server administrator's job not the pushing users's job. Either:
In unix land the former is easy to do using the "sticky group bit" and a "umask". On windows there's probably an even easier way that works only half the time. ;)