.hgignore没有为某个用户解析

时间：2010-11-26 15:15:53

标签： mercurial hgignore

我有一个受版本控制的项目，比如/project，.hgignore位于/project/.hgignore。它的语法似乎是正确的，但问题是某些用户完全忽略了这个文件，同时仍然为其他用户解析。

说，跑步

su -l dipsy -c 'cd /project; hg status'

显示正确的结果，忽略了正确的文件，而

su -l laalaa -c 'cd /project; hg status'

还会输出/project/.hgignore中列出的文件。

我已经检查了什么：

  • ~/.hgrc文件对于两个用户都是相同的，hg showconfig的输出也是如此。
  • 两位用户都可以阅读/project/.hgignore并写信给他们。

我错过了什么？

（以防万一：Debian Lenny，Mercurial 1.6.3）

//很抱歉，如果用户名看起来很愚蠢，那么它们就不是真的（：

- 添加2010-11-26 -

PS。有没有办法在处理.hgignore时启动hg并获得调试输出？ hg --debug status和hg status --debug不打印任何合理的内容。

- 添加2010-11026 -

调试hg status（结果各不相同）：

# su -l dipsy -c 'cd /project; strace hg status 2>&1 >/dev/null | grep hgignore'
open("/project/.hgignore", O_RDONLY|O_LARGEFILE) = 4
fstatat64(4, ".hgignore", {st_mode=S_IFREG|0664, st_size=214, ...}, AT_SYMLINK_NOFOLLOW) = 0
write(1, "M .hgignore\nM foo/bar/baz"..., 4096) = 4096

# su -l laalaa -c 'cd /project; strace hg status 2>&1 >/dev/null | grep hgignore'
write(1, "M .hgignore\nM foo/bar/baz"..., 4096) = 4096

调试hg status --ignore（结果相同）：

# su -l dipsy -c 'cd /project; strace hg status --ignore 2>&1 >/dev/null | grep hgignore'
open("/project/.hgignore", O_RDONLY|O_LARGEFILE) = 3
fstatat64(3, ".hgignore", {st_mode=S_IFREG|0664, st_size=214, ...}, AT_SYMLINK_NOFOLLOW) = 0

# su -l laalaa -c 'cd /project; strace hg status --ignore 2>&1 >/dev/null | grep hgignore'
open("/project/.hgignore", O_RDONLY|O_LARGEFILE) = 3
fstatat64(3, ".hgignore", {st_mode=S_IFREG|0664, st_size=214, ...}, AT_SYMLINK_NOFOLLOW) = 0

因此，/project/.hgignore在运行hg status --ignore时被读取，如果只运行hg status则被跳过。 WTF？

5 个答案:

答案 0 :(得分：6)

答案1 - Dirstate Repository Corruption

我昨晚也遇到了这个问题，这让我一直试图找到原因。我最终在dirstate repository corruption找到了一个wiki页面。涉及运行hg verify的第一步不起作用。第二步，克隆回购，确实有效！然后我删除了原始的.hg目录，并将克隆的.hg目录复制到原始位置。

我猜你在答案中，涉及提交/推送的步骤可能已经修复了存储库中的损坏。

答案2 - inotify扩展错误

在我最初解决问题并发布我的答案之后，问题继续弹出，但以不同的方式：Mercurial似乎部分服从.hgignore文件，但我对它所做的任何更新都没有生效。我碰巧正在玩创建一个脚本来创建几个相关的存储库，一段时间后我注意到我的机器内存不足。我运行了ps -e，所有这些hg进程都在内存中。所有这些过程都是inotify服务器。

Inotify是Mercurial附带的扩展，它为工作目录中的任何更改订阅，以提高hg status在大型存储库上的性能。 inotify extension page提到“它绝对必须被认为是实验性的”。似乎inotify服务器中的一些错误阻止Mercurial意识到.hgignore文件已更新，因此hg status总是使用.hgignore的陈旧版本。

试试我的理论并暂时让hg刷新.hgignore我执行了：

killall -s 2 hg

此命令告诉所有驻留的inotify服务器退出。 （killall与kill类似，但是将信号发送给具有给定名称的所有进程。-s 2参数发送INT信号，允许inotify正常关闭。）

之后，事情开始工作得非常好，但inotify服务器在执行hg后不断弹出。为了阻止我将以下代码段放在我的hgrc file：

中 
[extensions]
hgext.inotify = !

这会禁用inotify扩展名（!指示Mercurial禁用扩展名）。我的存储库足够小，我现在不需要它。

答案 1 :(得分：1)

两个用户都运行相同版本的hg吗？他们都有权阅读.hgignore文件吗？

答案 2 :(得分：1)

槽糕。只是为了确定，什么命令告诉你它们被解析为某些用户并被其他用户忽略？你是否用hg status --ignored确认了这个问题？有时人们会忘记'hg add'会覆​​盖被忽略的文件状态，所以如果一个用户已经添加（并且可能已经提交）那些文件但没有被推送添加到回购对方正在查看那么那个人可以很容易地认为他们的hgignore不是正在被咨询的时候，只是添加的文件会使忽略无关紧要。

如果是我，我接下来继续使用strace。像strace hg status --ignored | grep hgignore之类的东西，比较两个用户的输出。

答案 3 :(得分：1)

Mercurial是用python编写的，因此找出发生的事情不应该太难。你只需在mercurial/ignore.py中添加跟踪（只需使用warn（）函数，它的目的是从mercurial命令向控制台打印警告）。如果您在warn("I'm here")函数pat = {}之前放置def ignore(root, files, warn)，则每次考虑.hgignore时都会打印警告“我在这里”。在那之后，由你来决定是否有正确的痕迹来理解这种行为。如果你知道python，它不应该花费几分钟。

答案 4 :(得分：1)

Grea ^ W取得了一些成功。

另一个hg存储库隐藏在其中一个子文件夹中，这似乎是所描述问题的最可能原因。我想在我实际需要的那个之前读了另一个.hgignore，并且删除了所有以下.hgignore - s。

然而，将该存储库移出并在其位置留下符号链接并没有帮助。

然后，我决定采取行动：

  • 从~/.hgcookies删除了一个Cookie（我猜是由Kiln身份验证模块创建的）
  • 完全删除了/project/.hgignore
  • 删除了符号链接到其他存储库（如上所述）
  • 将[ui] ignore = .hgignore添加到~/.hgrc
  • 提交/推送更改
  • 重新创建/project/.hgignore，添加/已提交/再次推送
  • 添加了符号链接 - 现在任何一个用户都会忽略它

不确定哪个步骤完全符合要求，但现在看起来一切正常，每个用户都会解析/project/.hgignore。

[ui] ignore = .hgignore不是解决方案，因为我后来删除它并没有破坏任何东西。

所以，问题已经解决，但WTF仍未得到答复（：

谢谢大家。 是的，不要依赖嵌套的存储库。

相关问题
最新问题