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.
#!/usr/bin/env python
from __future__ import absolute_import
__doc__ = """Same as `echo a >> b`, but ensures a changed mtime of b.
Without this svn will not detect workspace changes."""
import os
import stat
import sys
text = sys.argv[1]
fname = sys.argv[2]
f = open(fname, "ab")
try:
before = os.fstat(f.fileno())[stat.ST_MTIME]
f.write(text)
f.write("\n")
finally:
f.close()
inc = 1
now = os.stat(fname)[stat.ST_MTIME]
while now == before:
t = now + inc
inc += 1
os.utime(fname, (t, t))
now = os.stat(fname)[stat.ST_MTIME]