On Mon, 20 Feb 2017 09:38:13 -0500, Yuya Nishihara <y...@tcha.org> wrote:
On Thu, 16 Feb 2017 16:41:10 -0500, Matt Harbison wrote:
# HG changeset patch
# User Matt Harbison <matt_harbi...@yahoo.com>
# Date 1486877030 18000
# Sun Feb 12 00:23:50 2017 -0500
# Node ID 38babd487181374325f3d27c5bc081dadf31b9b9
# Parent 27a4bc77e8b8e50abc76c387f117082e5853c47e
serve: make the URL the same for `hg serve` and `hg serve -S`
elif not virtual:
+ if self._rootrepo:
+ # Redirect '/' to the main repo when -S is given.
+ path = '/' + self._rootrepo
+ if self.prefix:
+ path = '/' + self.prefix + path
+ req.headers.append(('Location', path))
+ html = '<html>Moved <a href="' + path +
'">here</a>.</html>'
+ req.respond(HTTP_MOVED_PERMANENTLY, "text/html",
body=html)
+ return []
Suppose "hg serve" is used for temporarily serving random repositories,
301
seems too strong.
The temporary serve is the case that I'm interested in. It may not be
clear from this snippet, but the redirect is only reachable when using `hg
serve -S`, not random repos listed in a --web-conf file.
I guess I didn't think it was too strong, because the repo never is at
'/'. Once the `hg serve` process is killed, everything is gone.
Everything goes away eventually. But until then, it's a permanent
redirect.
The temporary/permanent distinction is important, because there needs to
be a trigger to update paths.default in hgrc without doing so for
temporary redirects. The updated hgrc path is important, because the
subrepo is cloned relative to the parent repo's paths.default value.
(Keeping both the sub=sub and sub=../sub style paths working in the two
new tests were one of the many headaches with this.)
Since nothing other than hg clients should see the redirect, do you have a
specific concern? (I haven't paid much attention to chg to know if it
would somehow cache the URL and get directed wrong when `hg serve` is
killed and something else is served. But the aggressive caching done by
web browsers is why I limited the redirect as narrowly as possible.)
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
