Permissions mercurial更新时重置组权限

我已经根据这里描述的文档配置了我的hg存储库：

但是，当我执行“hg update-C”在本地重新创建工作副本时，文件权限已更改，因此当其他开发人员尝试提交更改时，它最终会导致推送错误。假设，当配置正确时，hg update将保留文件权限。但它似乎没有这样做：

-rwxrwxr-x 1 root mercurial 2948 2010-06-24 15:27 .hg/store/data/src/public/index.php.i

vs.（删除工作副本并使用“hg update-C”重新创建后的实际源文件）

如何配置mercurial，以便在用户创建新文件或修改现有文件时，保留组及其权限

---

更新

2010.06.28

以下是我看到的错误示例：

remote: resolving manifests
remote: getting src/configs/application.ini
remote: abort: Permission denied: /hg/repo/path/src/configs/application.ini
remote: warning: changegroup hook exited with status 255
remote: calling hook changegroup.notify: hgext.notify.hook

---

你到底用了哪种方法？详细描述您的设置

是的，mercurial确实记得提交时的文件权限。当您执行

hg update-C

时，它将使用上次提交时设置的权限重新创建文件

您的错误消息似乎表明存储库服务器上的存储库文件具有错误的权限/所有者，因此您无法使用hg push修改它们。这可能是因为有人以不同的存储库服务器用户身份提交和推送文件

我建议使用共享ssh方法（）：您为存储库管理设置单独的用户帐户，添加开发人员的ssh公钥（您应该将它们限制为仅用于特定存储库的mercurial），然后使用

ssh://hguser@服务器/path/to/repository

作为url

顺便说一句：如果用于推/拉的用户不在受信任列表中，默认情况下mercurial不会运行任何挂钩。请参阅

man hgrc

中的受信任部分

---

BTW2：不要以root用户身份运行任何常规软件。使用普通帐户。

我遇到了同样的问题，通过在远程回购目录上设置粘性位解决了这个问题

chmod+s`find-d型`

---

这将解决OP遇到的问题。

Mercurial只跟踪“可执行”权限，而不跟踪用户或组。原始海报克隆中更改所有者的

.hg/store/data

文件可能会被运行为

root

的脚本所触动。您的本地文件用户/组所有权与远程显示的内容无关——用户/组根本不属于更改的一部分。新文件的权限来自远程回购的操作系统——下面twokats的答案和粘性组位应该满足您的需要。

remote: resolving manifests
remote: getting src/configs/application.ini
remote: abort: Permission denied: /hg/repo/path/src/configs/application.ini
remote: warning: changegroup hook exited with status 255
remote: calling hook changegroup.notify: hgext.notify.hook