view tests/test-sparse-fsmonitor.t @ 34682:7e3001b74ab3

tersestatus: re-implement the functionality to terse the status

The previous terse status implementation was hacking around os.listdir() and was
flaky. There have been a lot of instances of mercurial buildbots failing
and google's internal builds failing because of the
hacky implementation of terse status. Even though I wrote the last
implementation but it was hard for me to find the reason for the flake.

The new implementation can be slower than the old one but is clean and easy to
understand.

In this we create a node object for each directory and create a tree
like structure starting from the root of the working copy. While building the
tree like structure we store some information on the nodes which will be helpful
for deciding later whether we can terse the dir or not.
Once the whole tree is build we traverse and built the list of files for each
status with required tersing.

There is no behaviour change as the old test, test-status-terse.t passes with
the new implementation.

Differential Revision: https://phab.mercurial-scm.org/D985

This test doesn't yet work due to the way fsmonitor is integrated with test runner

  $ exit 80

test sparse interaction with other extensions

  $ hg init myrepo
  $ cd myrepo
  $ cat > .hg/hgrc <<EOF
  > [extensions]
  > sparse=
  > strip=
  > EOF

Test fsmonitor integration (if available)
TODO: make fully isolated integration test a'la https://github.com/facebook/watchman/blob/master/tests/integration/WatchmanInstance.py
(this one is using the systemwide watchman instance)

  $ touch .watchmanconfig
  $ echo "ignoredir1/" >> .hgignore
  $ hg commit -Am ignoredir1
  adding .hgignore
  $ echo "ignoredir2/" >> .hgignore
  $ hg commit -m ignoredir2

  $ hg sparse --reset
  $ hg sparse -I ignoredir1 -I ignoredir2 -I dir1

  $ mkdir ignoredir1 ignoredir2 dir1
  $ touch ignoredir1/file ignoredir2/file dir1/file

Run status twice to compensate for a condition in fsmonitor where it will check
ignored files the second time it runs, regardless of previous state (ask @sid0)
  $ hg status --config extensions.fsmonitor=
  ? dir1/file
  $ hg status --config extensions.fsmonitor=
  ? dir1/file

Test that fsmonitor ignore hash check updates when .hgignore changes

  $ hg up -q ".^"
  $ hg status --config extensions.fsmonitor=
  ? dir1/file
  ? ignoredir2/file