tests/helpers-testrepo.sh

match: making visitdir() deal with non-recursive entries

Primarily as an optimization to avoid recursing into directories that will
never have a match inside, this classifies each matcher pattern's root as
recursive or non-recursive (erring on the side of keeping it recursive,
which may lead to wasteful directory or manifest walks that yield no matches).

I measured the performance of "rootfilesin" in two repos:
- The Firefox repo with tree manifests, with
  "hg files -r . -I rootfilesin:browser".
  The browser directory contains about 3K files across 249 subdirectories.
- A specific Google-internal directory which contains 75K files across 19K
  subdirectories, with "hg files -r . -I rootfilesin:REDACTED".

I tested with both cold and warm disk caches. Cold cache was produced by
running "sync; echo 3 > /proc/sys/vm/drop_caches". Warm cache was produced
by re-running the same command a few times.

These were the results:

               Cold cache           Warm cache
             Before   After      Before   After
firefox      0m5.1s   0m2.18s   0m0.22s  0m0.14s
google3 dir  2m3.9s   0m1.57s   0m8.12s  0m0.16s

Certain extensions, notably narrowhg, can depend on this for correctness
(not trying to recurse into directories for which it has no information).

# The test-repo is a live hg repository which may have evolution
# markers created, e.g. when a ~/.hgrc enabled evolution.
#
# Tests are run using a custom HGRCPATH, which do not
# enable evolution markers by default.
#
# If test-repo includes evolution markers, and we do not
# enable evolution markers, hg will occasionally complain
# when it notices them, which disrupts tests resulting in
# sporadic failures.
#
# Since we aren't performing any write operations on the
# test-repo, there's no harm in telling hg that we support
# evolution markers, which is what the following lines
# for the hgrc file do:
cat >> $HGRCPATH << EOF
[experimental]
evolution=createmarkers
EOF