Linux Mercurial ACL可防止拉伤

请帮助我理解Mercurial与ACL结合的机制

我们的团队使用Mercurial作为版本控制系统。设置非常简单：两个开发人员（一个linux，一个windows），远程repo（linux）。每次windows用户W签入修改，而linux用户L希望随后拉取时，都会显示以下错误消息（取决于修改的文件）：

这是因为文件访问由linux的ACL列表处理。使用

setfacl

命令更正ACL权限后，一切都会顺利运行，并且L能够拖动。即使W克隆了具有正确权限的repo，

.hg

目录中的（新的/修改的）文件也具有错误的（默认）权限。repo的父文件夹具有正确的权限集，因此我不知道这些权限是从何处继承的

---

有人面临过类似的问题吗？提前谢谢你

在我的Linux机器上，我必须设置组权限的粘性位。基本上，当您创建一个将成为mercurial存储库的目录时，您需要使用

chmod g+s

，这将强制在该目录下创建的任何内容对组成员进行读/写/执行，而不管其默认的文件创建方式是什么。我使用的是标准的Unix组而不是ACL列表，因此我不确定这对您有何影响。

在内部创建新文件时。hg/store Mercurial从

.hg/store

目录本身复制（经典）文件权限，并使用编写用户的用户/组，除非用类似粘性组位的内容覆盖（如@Eric Y）所述。当修改其中一个文件时，如果用户的

umask

允许，它将保留现有的所有权和权限

据我所知，Mercurial没有对文件系统级ACL进行特殊处理——几乎没有工具这样做，这就是为什么ACL系统还包括继承规则，其中目录有自己的ACL，也有由该目录中新创建的对象继承的

default

ACL——也许您需要查看设置t除了设置其ACL之外，他还存储了默认ACL

也就是说，你确定你真的想使用ACL吗？如果你已经在使用它们并且熟悉它们，那就太好了，但是如果你只是为了在Mercurial中使用2-user-access而打破它们，那么你就在打赌使用一个专门的组（比如

开发人员

）和粘性组位或使用单个共享ssh帐户dev@unixhost每个都有单独的ssh私钥（有关示例，请参阅Mercurial wiki中的SharedSSH页面）

ACL非常强大，但很少有必要

---

其他读者注意：我们在这个问题上所说的与Mercurial的ACL扩展没有任何关系——它在Mercurial中，这是文件系统ACL级别的东西。

只有基于Debian的系统（如Ubuntu）的版本，但您应该检查一下。它以灵活的方式处理Mercurial repos的访问控制，但在文件系统ACL之外

pulling from ssh://user@domain.com
searching for changes
adding changesets
transaction abort!
rollback completed
abort: stream ended unexpectedly (got 0 bytes, expected 4)
remote: abort: Permission denied: /repopath/.hg/store/data/paper/tmp.txt.i