Sorry for the delay- I was swamped the last few days.
On Tue, 21 Feb 2017 09:33:58 -0500, Yuya Nishihara <y...@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 <y...@tcha.org>
wrote:
> On Thu, 16 Feb 2017 16:41:08 -0500, Matt Harbison wrote:
>> # HG changeset patch
>> # User Matt Harbison <matt_harbi...@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.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
