请帮助我理解Mercurial与ACL相结合的机制。
我们的团队使用Mercurial作为版本控制系统。设置非常简单：两个开发人员（一个Linux，一个窗口），远程仓库（linux）。每次，windows用户 W 检查修改并且linux用户 L 想要随后拉出，会显示以下错误消息（取决于更改的文件） ：
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
这是因为文件访问权限由linux的ACL列表处理。使用setfacl命令更正ACL权限后，一切运行顺畅， L 能够拉动。即使 W 以正确的权限克隆了repo，.hg目录中的（新/已修改）文件也具有错误（默认）权限。 repo的父文件夹具有正确的权限集，因此我不知道这些权限的继承地点。
有人遇到过类似的问题吗？提前谢谢！
答案 0 :(得分：1)
在我的Linux机器上，我必须为组权限设置粘滞位。基本上，当您创建一个将成为mercurial存储库的目录时，您需要使用chmod g+s <repoDirectory>这将强制在该目录下创建的任何内容对组成员具有读/写/执行权，而不管它们的文件创建默认值是什么。我使用的是标准的Unix组而不是ACL列表，所以我不确定这对你有什么帮助。
答案 1 :(得分：1)
在.hg / store中创建新文件时，Mercurial会复制.hg/store目录本身的（经典）文件权限，并使用写入用户的用户/组，除非被粘贴组位（如粘滞组位）覆盖@Eric Y）提到。修改其中一个文件时，如果您的用户umask允许，则会保留现有的所有权和权限。
据我所知，Mercurial没有对文件系统级ACL进行特殊处理 - 几乎没有工具，这就是ACL系统还包含继承规则的原因，其中目录有自己的ACL，并且还有default ACL由该目录中新创建的对象继承 - 除了设置其ACL之外，您可能需要考虑设置存储库default ACL。
那就是说，你确定你真的想要使用ACL吗？如果你已经在使用它们并且熟悉它们，这很好，但是如果你打破它们只是为了让2个用户访问在Mercurial工作那么你就打赌使用专用组（如developers）和粘性组位或使用单个共享ssh帐户dev @ unixhost，每个帐户都有单独的ssh私钥（例如，参见Mercurial wiki中的SharedSSH页面）。
ACL非常强大，但很少需要。
请注意其他读者：我们在这个问题中所说的任何内容都与Mercurial的ACL扩展无关 - 这是在Mercurial中，这是文件系统ACL级别的东西。
答案 2 :(得分：0)
基于Debian的系统（如Ubuntu）只有发行版，但您应该查看mercurial-server。它以灵活的方式处理Mercurial repos的访问控制，但不受文件系统ACL的影响。