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.
$ hg init base
$ cd base
$ echo 'alpha' > alpha
$ hg ci -A -m 'add alpha'
adding alpha
$ cd ..
$ hg clone base work
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd work
$ echo 'beta' > beta
$ hg ci -A -m 'add beta'
adding beta
$ cd ..
$ cd base
$ echo 'gamma' > gamma
$ hg ci -A -m 'add gamma'
adding gamma
$ cd ..
$ cd work
$ hg pull -q
$ hg merge
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
Update --clean to revision 1 to simulate a failed merge:
$ rm alpha beta gamma
$ hg update --clean 1
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd ..