[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