Mercurial ACL 防止拉取答案

【问题标题】：Mercurial ACL prevents pullMercurial ACL 防止拉取
【发布时间】：2012-06-11 11:40:29
【问题描述】：

请帮助我了解 Mercurial 与 ACL 的结合背后的机制。

我们的团队使用 Mercurial 作为版本控制系统。设置非常简单：两个开发人员（一个 linux，一个 windows），远程 repo（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 的父文件夹具有正确的权限集，所以我不知道这些权限是从哪里继承的。

有人遇到过类似的问题吗？提前谢谢！

【问题讨论】：

标签： linux mercurial acl

【解决方案1】：

在我的 Linux 机器上，我必须为组权限设置粘性位。本质上，当您创建一个将成为 mercurial 存储库的目录时，您需要使用 chmod g+s <repoDirectory> 这将强制在该目录下创建的任何内容都对组成员具有读/写/执行权限，而不管他们创建文件的默认设置是什么。我使用的是标准的 Unix 组而不是 ACL 列表，所以我不确定这对你有什么影响。

【讨论】：

【解决方案2】：

在 .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 级别的东西。

【讨论】：

【解决方案3】：

只有基于 Debian 的系统（如 Ubuntu）的版本，但您应该查看mercurial-server。它以灵活的方式处理 Mercurial 存储库的访问控制，但在文件系统 ACL 之外。

【讨论】：