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.有没有办法启动hg并在处理

.hgignore

-s时获得调试输出？

hg--debug status

和

hg status--debug

不要打印任何合理的内容

--新增2010-11026--

调试

hg状态

（结果不同）：

调试

hg状态--忽略
（结果相同）：

因此，在运行
hg status时读取
/project/.hgignore
，如果只运行
hg status
.WTF？
两个用户运行的是同一版本的
hg
？他们都有权读取.hgignore文件吗？
Hrm。可以肯定的是，什么命令告诉你它们是为s解析的一些用户和其他用户忽略了？您是否确认使用
hg status--ignored
？有时人们忘记了“hg add”覆盖了忽略的文件状态，因此如果一个用户已经添加（可能已提交）那些文件，但没有被推到其他人正在查看的repo中，那么这个人很容易认为他们的hgignore没有被咨询，而实际上只是添加的文件使ignore变得无关紧要

如果是我，我会继续使用
strace
下一步。类似于
strace hg status——ignored | grep hgignore
并比较两个用户的输出。
Mercurial是使用python编写的，从今以后发现发生了什么应该不会太难。只需在
Mercurial/ignore.py
中添加跟踪（只需使用warn（）函数，其目的是从mercurial命令向控制台打印警告）。如果您在函数
def ignore（root，files，warn）
的
pat={}
前面加上
warn（“我在这里”）
它应该打印警告“我在这里”每次它都会考虑到
.hgignore
。然后，您就可以要求正确的跟踪来理解该行为。如果您了解python，应该不会超过几分钟。
Grea^W取得了一些成功

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

然而，将该存储库移出并在其位置上留下一个符号链接并没有立即起到作用

然后，我决定采取激进的行动：


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

不确定哪一步确实起到了作用，但现在一切似乎都按预期进行，
/project/.hgignore
为每个用户解析

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

因此，问题已经解决，但WTF仍然没有答案（：

谢谢大家。是的，不要依赖嵌套存储库。
答案1-目录存储库损坏
我昨天晚上也遇到了这个问题，这让我迫不及待地想找出问题的原因。我最终在上找到了一个wiki页面。第一步是运行
hg verify
，但没有成功。第二步是克隆repo，成功了！然后我删除了原始的.hg目录，并将克隆的.hg目录复制到了o边缘位置

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


回答2-inotify扩展错误
在我最初修复了这个问题并发布了我的答案之后，这个问题继续出现，但方式不同：Mercurial似乎部分遵守了.hgignore文件，但我对它所做的任何更新都没有生效。我碰巧在创建一个脚本来创建几个相关的存储库，过了一会儿我注意到了这一点我运行了一个
ps-e
，所有这些
hg
进程都挂在内存中。所有这些进程都是inotify服务器

Inotify是Mercurial附带的一个扩展，它订阅工作目录中的任何更改，以提高大型存储库上
hg status
的性能。其中提到“它肯定必须被视为实验性的”。看来inotify服务器中的某些错误正在阻止Mercurial实现.hgignore文件已更新，因此
hg status
始终使用.hgignore的旧版本

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

killall -s 2 hg

此命令告诉所有驻留的inotify服务器退出。（
killall
类似于
kill
，但会将信号发送到所有进程
# 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

killall -s 2 hg

[extensions]
hgext.inotify = !