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:
~/.hgrc
files are identical for both users, so are outputs for hg showconfig
./project/.hgignore
and 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?
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 verify
didn'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.
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 -e
and there were all of these hg
processes 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 status
on 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 so hg status
always used a stale version of .hgignore.
To try my theory out and temporarily get hg to refresh .hgignore I executed:
killall -s 2 hg
This command tells all resident inotify servers to exit. (killall
is like kill
, but sends the signal to all processes with the given name. The -s 2
argument 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:
[extensions]
hgext.inotify = !
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.
Are both users running the same version of hg
? Do they both have permission to read the .hgignore file?
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With