tests/test-issue4074.t

hgweb: fallback to checking wsgireq.env for REPO_NAME for 3rd party hosting

Starting with d7fd203e36cc, SCM Manager began to 404 any repository access.
What's happening is that it is generating a python script that creates an hgweb
application (not hgwebdir), and launches hgweb via wsgicgi.  It must be setting
REPO_NAME in the process environment before launching this script, which gets
picked up and put into wsgireq.env when wsgicgi launches the hgweb application.
>From there, other variables (notably 'apppath' and 'dispatchpath') are
constructed differently.

  d7fd203e36cc^ (working):

    apppath: /hg/eng/devsetup
    dispatchpath:
    pathinfo: /eng/devsetup
    reponame: eng/devsetup

  d7fd203e36cc:

    apppath: /hg
    dispatchpath: eng/devsetup
    pathinfo: /eng/devsetup
    reponame: None
    REPO_NAME: eng/devsetup

Rather than having an existing installation break when Mercurial is upgraded,
just resume checking the environment.  I have no idea how many other hosting
solutions would break without restoring this.

#require no-pure

A script to generate nasty diff worst-case scenarios:

  $ cat > s.py <<EOF
  > import random
  > for x in range(100000):
  >     print
  >     if random.randint(0, 100) >= 50:
  >         x += 1
  >     print(hex(x))
  > EOF

  $ hg init a
  $ cd a

Check in a big file:

  $ $PYTHON ../s.py > a
  $ hg ci -qAm0

Modify it:

  $ $PYTHON ../s.py > a

Time a check-in, should never take more than 10 seconds user time:

  $ hg ci --time -m1
  time: real .* secs .user [0-9][.].* sys .* (re)