Mercurial 可以保留文件权限吗?

发布于 2024-08-02 07:02:36 字数 724 浏览 3 评论 0原文

我看过许多博客文章,并且亲身经历过,Mercurial 不会保留从一个存储库推送到另一个存储库的文件的权限。有谁知道可以保留权限的 Mercurial 扩展吗?我假设它不能用钩子来完成,因为钩子知道原始存储库的权限是什么?

请求的详细说明:

  • 如果对文件的唯一更改是权限更改(例如,chmod o+r filename),则尝试提交文件会失败,并显示一条消息,指出该文件尚未更改

  • 如果我提交一个权限为 600 (rw--------) 的文件,然后克隆存储库,则克隆中的同一文件的权限为 664 (rw-rw-r--):

    <前><代码>:nr@yorkie 6522; hg克隆一二 更新工作目录 1 个文件已更新、0 个文件已合并、0 个文件已删除、0 个文件未解决 :nr@约克6523; ls -l 一二 一: 总计 4 -rw-------- 1 nr nr 8 月 18 日 21:50 foo 二: 总计 4 -rw-rw-r-- 1 nr nr 8 月 18 日 21:51 foo

此示例显示 hgclone 不保留权限,但 hgpush 也不保留权限。

在我的应用程序中,一个存储库位于可公开访问的路径上,并且重要的是

  • 多个用户有权更改存储库

  • 公共存储库仅在显式设置为可读时才可读。

I've seen a number of blog posts, and have experienced for myself, that Mercurial does not preserve the permissions on files pushed from one repo to another. Does anyone know of a Mercurial extension that would preserve the permissions? I'm assuming it can't be done with a hook, because what does a hook know about permissions at the originating repo?

Requested elaboration:

  • If the only change to a file is a change in permissions (e.g., chmod o+r filename), attempts to commit the file fail with a message saying that the file has not changed.

  • If I commit a file with permissions 600 (rw-------), then clone the repo, the same file in the clone has permissions 664 (rw-rw-r--):

    : nr@yorkie 6522 ; hg clone one two
    updating working directory
    1 files updated, 0 files merged, 0 files removed, 0 files unresolved
    : nr@yorkie 6523 ; ls -l one two
    one:
    total 4
    -rw------- 1 nr nr 8 Aug 18 21:50 foo
    
    two:
    total 4
    -rw-rw-r-- 1 nr nr 8 Aug 18 21:51 foo
    

This examples shows that hg clone does not preserve permissions, but hg push does not preserve them either.

In my application, one repo is on a publically accessible path, and it's of major importance that

  • Multiple users have the right to change the repo

  • Files in the public repo become readable only when explicitly made readable.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

栀子花开つ 2024-08-09 07:02:36

看起来可以使用钩子和辅助工具(以及一点口香糖和打包线)来完成:

  1. 获取 David Hardeman 的 Metastore,用于保存和恢复文件元数据。

  2. 更改源代码,使其忽略目录 .hg 以及 .git

  3. 使用以下 Mercurial 挂钩:

     precommit.meta = metastore -s
    
     更改组.update = hg 更新
     update.meta = /usr/unsup/nr/bin/metastore -a
    

您必须将 .metadata 文件添加到存储库中。

此 lashup 在大多数情况下都有效,但如果您更改权限并希望传播它,则必须运行 metastore -s 才能推送这些更改进入 .metadata 文件,hg 将在其中看到更改;否则提交认为没有什么新鲜事。

It looks like it can be done using hooks and an auxiliary tool (and a little chewing gum and baling wire):

  1. Get David Hardeman's Metastore, which saves and restores file metadata.

  2. Alter the sources so it will ignore directory .hg as well as .git.

  3. Use the following Mercurial hooks:

     precommit.meta = metastore -s
    
     changegroup.update = hg update
     update.meta   = /usr/unsup/nr/bin/metastore -a
    

You have to add the .metadata file to the repo.

This lashup will work most of the time, but if you change only permissions and want to propagate it, you'll have to run metastore -s in order to push those changes into the .metadata file where hg will see the change; otherwise the commit thinks nothing is new.

抠脚大汉 2024-08-09 07:02:36

如何使用 Mercurial 常见问题解答中的解决方案:

如果您使用 Mercurial 进行配置
文件管理,您可能想要
跟踪文件属性(所有权和
权限)也。仅限 Mercurial
跟踪每个的可执行位
文件。

以下是如何保存的示例
属性以及文件(作品
在 Linux 上,如果您有 acl 软件包
已安装):

<前><代码># cd /etc && getfacl -R 。 >/tmp/acl.$$ && mv /tmp/acl.$$ .acl
# 汞提交

这远非完美,但你明白了。如需更复杂的解决方案,请查看 etckeeper。

What about using this solution from the Mercurial FAQ:

If you're using Mercurial for config
file management, you might want to
track file properties (ownership and
permissions) too. Mercurial only
tracks the executable bit of each
file.

Here is an example of how to save the
properties along with the files (works
on Linux if you've the acl package
installed):

# cd /etc && getfacl -R . >/tmp/acl.$ && mv /tmp/acl.$ .acl
# hg commit

This is far from perfect, but you get the idea. For a more sophisticated solution, check out etckeeper.

浮光之海 2024-08-09 07:02:36

对于 /etc 目录的具体情况, etckeeper 看起来很有趣。

For the specific case of the /etc directory, etckeeper looks interesting.

彩扇题诗 2024-08-09 07:02:36

我认为 metastore 是由于 死机而被废弃的软件作者网站上的 .git 链接,因此我将以下内容直接放置在存储库的 .hc/hgrc 配置文件中:

[paths]
default = ...

[hooks]
# NOTE: precommit is different than pre-commit, see https://www.mercurial-scm.org/repo/hg/help/hgrc for list of hooks
pre-commit  =
        # export permissions
        hg st -camn0 | sort -z | xargs -0 getfacl > .hg.hook.pre-commit.acl.export
        hg add .hg.hook.pre-commit.acl.export

        # export timestamps
        hg st -camn0 | sort -z | xargs -0 stat > .hg.hook.pre-commit.stat.export
        hg add .hg.hook.pre-commit.stat.export

update =
        # import permissions
        setfacl --restore=.hg.hook.pre-commit.acl.export

        # import timestamps
        # TODO: use touch to restore timestamps

I assumed that metastore was abandonware due to the dead git link on author's site so I whipped the below which is placed directly in repo's .hc/hgrc configuration file:

[paths]
default = ...

[hooks]
# NOTE: precommit is different than pre-commit, see https://www.mercurial-scm.org/repo/hg/help/hgrc for list of hooks
pre-commit  =
        # export permissions
        hg st -camn0 | sort -z | xargs -0 getfacl > .hg.hook.pre-commit.acl.export
        hg add .hg.hook.pre-commit.acl.export

        # export timestamps
        hg st -camn0 | sort -z | xargs -0 stat > .hg.hook.pre-commit.stat.export
        hg add .hg.hook.pre-commit.stat.export

update =
        # import permissions
        setfacl --restore=.hg.hook.pre-commit.acl.export

        # import timestamps
        # TODO: use touch to restore timestamps
苦妄 2024-08-09 07:02:36

将权限存储在 VCS 中并不是一个好主意。然而,Mercurial 支持“可执行”标志(这与权限不同,尽管在 Unix 中可执行标志是权限的一部分)。

It is not good idea to store permissions in VCS. However, Mercurial supports "executable" flag (that is not the same as permissions, although in Unix executable flag is part of permissions).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文