[PATCH 1 of 4 V2] serve: add support for Mercurial subrepositories

[Matt Harbison]

Sorry for the delay- I was swamped the last few days.

On Tue, 21 Feb 2017 09:33:58 -0500, Yuya Nishihara <yuya at tcha.org> wrote:

> On Mon, 20 Feb 2017 22:00:20 -0500, Matt Harbison wrote:
>> 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.
>
> Yes, that seems intuitive way to serve a repo and its subrepos behind. I
> thought there wasn't redirection magic as the parent repo was served at  
> '/',
> was there?

Correct. Redirection was only introduced in V2.

>> - 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.
>
> [snip]
>
> I saw some of these problems in V1. However, the standalone hgweb can  
> host
> a repository at '/', so I don't think it's quite difficult to host the  
> subrepo
> parent at '/'.

That's a good point, so now I'm really puzzled over the subtle  
differences.  It looks like when it finds a hosted repo, it just farms out  
to hgweb, like the single serve would do.

>> 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 '/'.
>
> I think (2) and (3) are up to how we build a repository map.

What I mean for (2) is that in V2, none of the code changes are hit  
without -S.  That seems like a good thing, given the subtle breakage in V1.

What I mean by (3) is that the transition for current clones is to simply  
drop --web-conf=.. and start using -S on the server side.  Clients won't  
see a difference.

I assume that the hardcoded web.staticurl in V1 also means that it won't  
be able to serve a subrepo named 'static'?  (That's admittedly an edge  
case.)

I only see the two ways to build the repo map, so I'm not sure what you  
are saying here.

> If a map has no
> '/' entry, hgweb would serve nothing at '/' and is compatible with the  
> current
> behavior.