With inotify enabled, files that should be ignored could be detected as
untracked by mercurial. This behavior was wrong because inotify's filestatus
implementation only matched filenames against ignore patterns, instead of
checking if other elements of their paths matched them. This patch fixes the
behavior by checking the file paths against the ignore patterns.
A new test has also been added to the main inotify test to prevent any
regressions.
* prefix messages by inotify-(client|server)
* make sure that all warning and abort messages use the same format.
* in the case where inotify.sock is an old broken symlink, say so and abort
instead of trying to overwrite the already existing link
This will mainly help us in our tests to log pids of inotify servers
started implicitely, to make sure that unkilled inotify daemons do not clutter
the output of unrelated tests.
Also desactivate the workaround introduced in 37824a274d63
The fact that a parent process spawns a daemon does not necessarily means that
it is the only think it has to do. This was forcing since e8efd88001e7 inotify
processes launched implicitely to exit prematurely:
when no inotify server was running, "hg st" for example would only launch a
inotify server, _exit(0) and thus would not return file statuses.
This changeset adds a test for implicitely launched inotify processes.
Change to output of test-inotify-1208 is correct: it reflects the normal
error message of "hg st" when not dying during "hg inserve" daemon creation.
Emulate the match.dir calls that are made in dirstate.walk:
* first mark the visited directories on the server side
* then extend the transmitted response to include this directory list
* and lastly call match.dir on each directory
The biggest problem was the data structure, which did not allow changing
a file into a directory or vice versa. This problem is fixed by 47d29dcb7266.
The walk() method also had an issue in this case:
- we know 'path' as a directory. inotify server sleeps.
- 'path' is deleted
- 'path' is recreated as a file
- the server catches up here, and see the deletion. it instantiates a scan(),
which in its turn calls for walk(repo, path).
- walk() then assumes that 'path' is a directory and calls os.listdir on it,
which raises an OSError(errno.ENOTDIR)
Catch the error, and yield the file instead of the directory contents.
