[PATCH 1 of 4 V2] serve: add support for Mercurial subrepositories
Matt Harbison
mharbison72 at gmail.com
Mon Feb 20 22:00:20 EST 2017
On Mon, 20 Feb 2017 09:27:44 -0500, Yuya Nishihara <yuya at tcha.org> wrote:
> On Thu, 16 Feb 2017 16:41:08 -0500, Matt Harbison wrote:
>> # HG changeset patch
>> # User Matt Harbison <matt_harbison at yahoo.com>
>> # Date 1486875517 18000
>> # Sat Feb 11 23:58:37 2017 -0500
>> # Node ID 4f2862487d789edc1f36b5687d828a2914e1dc32
>> # Parent afaf3c2b129c8940387fd9928ae4fdc28259d13c
>> serve: add support for Mercurial subrepositories
>>
>> I've been using `hg serve --web-conf ...` with a simple '/=projects/**'
>> [paths]
>> configuration for awhile without issue. Let's ditch the need for the
>> manual
>> configuration in this case, and limit the repos served to the actual
>> subrepos.
>>
>> This doesn't attempt to handle the case where a new subrepo appears
>> while the
>> server is running. That could probably be handled with a hook if
>> somebody wants
>> it. But it's such a rare case, it probably doesn't matter for the
>> temporary
>> serves.
>>
>> Unfortunately, the root of the webserver when serving multiple repos is
>> the html
>> index file. This makes the URL different for `hg serve` vs `hg serve
>> -S`,
>> because the top level repo then needs to be part of the path. That can
>> be
>> fixed later.
>
> I'm puzzled by this new version which extensively relies on somewhat
> magical
> HTTP redirection. Instead, can't we fix hgwebdir to be able to host
> hgweb at
> '/' URL, and add explicit URL to show the index page hidden by it?
This patch is the same as the first in V1, except that I dropped forcing
the web.staticurl config, and I globbed away a bunch of the http
parameters in the tests, since only the URI and status is of interest.
The first version did host the parent at '/', and the subrepos relative to
it. I switched from that, not because of the index hiding, but because of
all the problems I ran into.
First were problems (I don't remember all of the details, but eventually
managed to fix) with `hg` commands. And then I noticed that the initial
repo view wasn't rendering properly in the browser. There was output from
the server like this:
127.0.0.1 - - [20/Feb/2017 21:02:36] "GET / HTTP/1.1" 200 -
127.0.0.1 - - [20/Feb/2017 21:02:42] "GET /favicon.ico HTTP/1.1" 404 -
That seemed to be fixed by the staticurl config. I was also able to load
"http://localhost:8000/subrepo" and get it to display properly, so I
submitted it. But I waved Augie off because then I noticed more problems
in the browser:
- At http://localhost:8000, the links on the left side were corrupt (graph
is simply 'graph/tip', tags is 'http://tags', etc.) The pattern seemed to
be that things ending in 'tip' are relative URLs, and the rest get an
http: prefix. It looks from the sources like it is just a matter of '/'
not translating for the {repo} template.
- At http://localhost:8000/subrepo, all of the links on the left look
proper. But if you click on one that ends in 'tip' (like 'graph'), the
page doesn't render properly (like when 'staticurl' wasn't set on the
parent repo). It does properly render pages that don't end in 'tip', like
'branches'.
I also had a different failed attempt at hosting the parent at '/' a few
years ago, which had the same rendering issues. And I didn't check
anything other than paper. All in all, a week or so of nonstop problems
convinced me that I was going about this the wrong way.
To me, the benefits of this series over the original is:
1) The repos aren't moved, and therefore don't incur these subtle bugs
2) These changes are totally isolated to subrepo serving, so there should
be no risk to mainstream hgweb usage
3) This is completely compatible with existing serves with a simple
'/=$projects_dir/**' config file, because the real repos are not anchored
to '/'.
>
> That will be useful without subrepos. Currently we can't see the index
> page '/foo' if we have a repository '/foo' and '/foo/bar'.
I actually wondered why there wasn't an explicit index.html handled where
needed, and maybe a redirect to it. I don't think doing that is
incompatible with this series though.
More information about the Mercurial-devel
mailing list