.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 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< /code> 会在运行 hg status --ignore 时读取，如果仅运行 hg status 则会跳过 WTF？
I have a project under version control, say, in /project, and .hgignore located at /project/.hgignore. Its syntax seems correct, but the problem is this file is completely ignored for certain users while still parsed for the others.
Say, running
su -l dipsy -c 'cd /project; hg status'
shows correct results with proper files ignored, while
su -l laalaa -c 'cd /project; hg status'
also outputs files listed in /project/.hgignore.
What I checked already:
~/.hgrcfiles are identical for both users, so are outputs forhg showconfig.- Both users can read
/project/.hgignoreand write to that.
What am I missing?
(Just in case: Debian Lenny, Mercurial 1.6.3)
// Sorry if usernames seem stupid, they are not real (:
-- added 2010-11-26 --
PS. Is there any way to launch hg and get the debug output on processing .hgignore-s? hg --debug status and hg status --debug do not print anything sensible.
-- added 2010-11026 --
Debugging hg status (results vary):
# 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
Debugging hg status --ignore (results are the same):
# 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
So, /project/.hgignore is read when running hg status --ignore and skipped if running just hg status. WTF?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
太棒了^W 取得了一些成功。
其中一个子文件夹中隐藏着另一个 hg 存储库，这似乎是造成所描述问题的最可能原因。我猜想另一个
.hgignore在我实际需要的之前被读取，并且所有以下.hgignore-s 都被删除了。然而，将该存储库移出并在其位置上留下符号链接并不能立即起到帮助作用。
然后，我决定采取彻底的行动：
~/.hgcookies中删除了一个cookie（我猜是由Kiln身份验证模块创建的）/project/.hgignore[ui]ignore = .hgignore添加到~/.hgrc/project/.hgignorecode>，再次添加/提交/推送哪一步完全达到了目的，但现在一切似乎都按预期工作，
/project/.hgignore为每个用户进行解析。[ui]ignore = .hgignore不是解决方案，因为我后来删除了它并且它没有破坏任何东西。所以，问题解决了，但 WTF 仍然没有答案（：
谢谢大家。
是的，不要依赖嵌套存储库。Grea^W Some success.
There was another hg repository hiding in one of the subfolders, this seems the most probable cause of the problems described. I guess the another
.hgignorewas read before the one I actually needed, and all the following.hgignore-s were dropped.However, moving that repository out and leaving a symlink on its place did not help at once.
Then, I decided to act radically:
~/.hgcookies(I guess created by Kiln authentication module)/project/.hgignoreat all[ui] ignore = .hgignoreto~/.hgrc/project/.hgignore, added/committed/pushed againNot sure which step exactly did the trick, but everything seems working as expected now,
/project/.hgignoreis parsed for every user.[ui] ignore = .hgignoreis not the solution as I removed it later and it did not break anything.So, the problem is solved but WTF is still unanswered (:
Thank you all.
And yes, do not rely on nested repositories.答案 1 - Dirstate 存储库损坏
我昨晚也遇到了这个问题，它让我苦苦寻找其原因。我最终找到了一个关于 dirstate 存储库损坏 的 wiki 页面。涉及运行
hg verify的第一步不起作用。第二步，克隆存储库，成功了！然后，我删除了原始 .hg 目录，并将克隆的 .hg 目录复制到原始位置。我猜测在您的回答中，涉及提交/推送的步骤可能已经修复了存储库中的损坏。
答案 2 - inotify 扩展错误
在我最初修复问题并发布答案后，问题继续出现，但以不同的方式：Mercurial 似乎部分遵守 .hgignore 文件，但我对其所做的任何更新都没有生效。我碰巧正在创建一个脚本来创建几个相关的存储库，过了一会儿我注意到我的机器内存不足。我运行了 ps -e ，所有这些 hg 进程都挂在内存中。所有这些进程都是 inotify 服务器。
Inotify 是一个扩展，随 Mercurial 一起提供，它订阅工作目录中的任何更改，以提高大型存储库上
hg status的性能。 inotify 扩展页面提到“它绝对必须被视为实验性的”。 inotify 服务器中的一些错误似乎阻止了 Mercurial 意识到 .hgignore 文件已更新，因此hg status始终使用过时版本的 .hgignore。为了验证我的理论并暂时让 hg 刷新 .hgignore，我执行了：
此命令告诉所有驻留的 inotify 服务器退出。 （
killall类似于kill，但将信号发送到具有给定名称的所有进程。-s 2参数发送 INT 信号，该信号允许inotify 正常关闭。）之后，一切开始工作得很好，但 inotify 服务器在执行 hg 后不断弹出。为了阻止这种情况，我将以下代码片段放入我的 hgrc 文件 中：
这将禁用 inotify扩展（
!指示 Mercurial 禁用该扩展）。我的存储库足够小，我现在不需要它。Answer 1 - Dirstate Repository Corruption
I just had this problem as well last night and it was driving me up the wall trying to find the cause of it. I eventually found a wiki page on dirstate repository corruption. The first step involving running
hg verifydidn't work. The second step, cloning the repo, did work! I then deleted the original .hg directory and copied the clone's .hg directory to the orginal location.I'm guessing that in your answer, the steps involving commiting/pushing may have fixed the corruption in your repository.
Answer 2 - inotify extension bug
After I originally fixed the problem and posted my answer, the problem continued to pop up, but in a different manner: Mercurial seemed to be partially obeying the .hgignore file, but any updates I made to it did not take effect. I happened to be playing around creating a script to create several related repositories, and I noticed after a while that my machine was running out of memory. I ran a
ps -eand there were all of thesehgprocesses hanging around in memory. All of those processes were inotify servers.Inotify is an extension, shipped with Mercurial, which subscribes to any changes in your working directory in order to improve the performance of
hg statuson large repositories. The inotify extension page mentions that "it definitely has to be considered experimental". It seems that some bug in the inotify servers is preventing Mercurial realizing the .hgignore file has been updated and sohg statusalways used a stale version of .hgignore.To try my theory out and temporarily get hg to refresh .hgignore I executed:
This command tells all resident inotify servers to exit. (
killallis likekill, but sends the signal to all processes with the given name. The-s 2argument sends the INT signal which allows inotify to shutdown gracefully.)After that, things started working very nicely, but inotify servers kept popping up after executing hg. To stop that I put the following snippet in my hgrc file:
This disables the inotify extension (the
!instructs Mercurial to disable the extension). My repositories are small enough that I don't need it for now.两个用户是否运行相同版本的
hg？他们都有权读取 .hgignore 文件吗？Are both users running the same version of
hg? Do they both have permission to read the .hgignore file?嗯。只是为了确定一下，什么命令告诉您它们已被某些用户解析，而其他用户则被忽略？您是否使用
hg status --ignored确认这一点？有时人们会忘记“hg add”会覆盖忽略的文件状态，因此，如果一个用户已经添加（并且可能提交）这些文件但没有将其推送到其他人正在查看的存储库中，那么该人很容易认为他们的 hgignore 不是被咨询时实际上只是添加的文件使忽略无关紧要。如果是我，我接下来会继续使用
strace。像 strace hg status --ignored | 这样的东西grep hgignore 并比较两个用户的输出。Hrm. Just to be sure, what command is telling you they're parsed for some users and ignored from others? Are you confirming that with
hg status --ignored? Somtimes people forget that 'hg add' overrides ignored file status, so if one user has already added (and maybe committed) those files but not pushed that add to the repo the other is viewing then that person can easily think their hgignore isn't being consulted when really it's just that added files make ignore irrelevant.Were it me I'd move on to using
stracenext. Something likestrace hg status --ignored | grep hgignoreand compare the output for two users.Mercurial 是使用 python 编写的，因此找出发生的情况应该不会太难。您只需将跟踪放入 Mercurial/ignore.py 中（只需使用 warn() 函数，其目的是从 Mercurial 命令将警告打印到控制台）。如果您将
warn("I'm here")放在函数defignore(root, files, warn)pat = {} 之前code> 每次考虑到.hgignore时，它都应该打印警告“我在这里”。之后，您需要询问正确的痕迹来了解该行为。如果你了解 python，应该不会超过几分钟。Mercurial is written using python, henceforth finding out what happens should not be too hard. You just put traces in
mercurial/ignore.py(simply use the warn() function, it's purpose is to print warnings to console from mercurial commands). If you putwarn("I'm here")just before ofpat = {}in the functiondef ignore(root, files, warn)it should print the warning "I'm here" each time it takes into account the.hgignore. After that, it's up to you to ask for the right traces to understand the behavior. If you know python, it should not take more than a few minutes.