Since the 'summary' view used by e.g. gitweb and monoblue shows both a
changelog and a bookmarks list, the same changes are needed here as were
made to the 'changelog' and 'bookmarks' web commands (2be8fa4eef83 and
70f6745775fa, respectively).
The internal WSGI emulation in wsgicgi.py was not fully WSGI compliant and
assumed that all responses sent a body. With a9df76d7ca1f that caused a real
bug when using hgweb.cgi.
wsgicgi.py will now make sure headers always are sent, using the pattern from
PEP 333 and similar to how it is done in 38e07483cc16.
The web.prefix setting was being ignored when creating the index URL
breadcrumbs.
We only need to fix hgwebdir and not hgweb because hgweb gets the complete URL
request, including the prefix, while hgwebdir gets a "subdir" which does not
include the prefix.
This fix is slightly different of what was suggested on the bug tracker. In
there it was suggested to hide the prefix itself from the breadcrumb. I think
that would be a better solution, but it would require changing all the index
templates and passing the prefix to the template engine, which may be too big
a change for stable during the freeze. For now this fixes the problem, and the
fix could be improved during the next cycle.
This options add a new `web.view` to control filter level of hgweb.
This option have two purposes:
1) Allow fall back to unfiltered version in case a yet undetected by critical
bug is found in filtering after 2.5 release
2) People use hgweb as a local repoviewer. When they have secret changesets,
they wants to use "visible" filter not "served"
(modified by mpm, documentation deferred)
I noticed that access to filtered revision returned HTTP 500 code (internal
server error). Investigation shown that it was the case for unknown revision
too. That wrong and we now properly return a 404 for revision not found.
This changeset enable the "served" filter on all repo used by hgweb.
Hgweb misbehave in a lot of when filtering changeset are present but I do not
expect normal people to have secret or obsolete changeset on they server.
Misbehavior will be gradually fixed later.
This is necessary to enforce filtering. The result is a bit buggy (may provide
less changeset than expected, but it will stop crashing on filtered revision
access.
Note that changelog.revs can not represents empty iteration like xrange did. So
we have to explicitly prevent call when there is nothing to do.
This changeset checks that a revision is known before adding it to the
navigation.
This will prevent traceback on filtered repository. This changeset result in an
incorrect behaviors, Navigation link may be dropped without any replacement.
However this bad navigation generation is much better than a crash
For compatibility with changelog filtering we need access to the changelog, a
simple nodefunc is not sufficient, only the changelog and repo have access the
filteredrevs information.
For the filerevnav version, we use an unfiltered changelog. Linkrev is currently
broken with filtering and we need some failsafe to prevent traceback. This is
the same approach as the one used in 83a1b777fc02. The use of
filectx.changectx() allowed the previous code to use the 83a1b777fc02 hack.
This changeset may result in an incorrect behaviors, Navigation
link may point to missing revision. However this bad navigation
generation is much better than a plain crash
This abstraction have two advantages:
- If the revlog is empty, None of the code bellow is relevant,
early returns seems a win.
- Abtraction of the 'emptiness' check will help later when we stop relying on
nodefunc.
A bonus, with filtering, a non-empty revlog may not have '0' revision
accessible. It'll be easier to handle with the emptiness test in a dedicated
function
For later compatibility with changelog filtering some part of the navigation
generation logic will be altered. Those altered part will be different when in
the changelog case and in the filelog case. Moving this into an object will
allow to use inheritance to override just the part of the logic we need.
The aimed logic are for example:
- generation of revision 'hex' (different logic for changelog and filelog)
- revlog emptyness test
- fetching of the first revision of a revlog (may not be 0)
The `limit` argument of several generator have only two possible values in
practice: 0 and 1. We rename this parameter to `latestonly` and simplify it's
handling.
The simplification allows us to save fetching of data that we are sure to not
consume.
Having a function minimal function perimeter will helps future refactoring.
Fixes HTTP protocol violation introduced in e4a5f5db7028. 'hg serve' would show
a stacktrace when loading pages that not had been modified.
There was test coverage for this, but the wrong response headers wasn't shown
and thus not detected.
'hg serve' used to close connections when sending a response with unknown
length ... such as a bundle or archive.
Now chunked encoding will be used for responses with unknown length, and the
connection do thus not have to be closed to indicate the end of the response.
Chunked encoding is only used if the length is unknown, if the connection
wouldn't be closed for other reasons, AND if it is a HTTP 1.1 request.
This will not benefit other users of hgweb ... but it can serve as an example
that it can be done.
hgweb internals will often produce empty writes - especially when returning
compressed data. hgweb is no middleware application and there is thus no
reason to pass them on to be processed in other layers.
The purpose of this change is to make it much easier to navigate up the
repository tree when the hg web server is used to serve more than one
repository.
A "URL breadcrumb" is a path where each of the path items can be clicked to go
to the corresponding path page.
This lets you go up the folder hierarchy very quickly. For example, when showing
the list of repositories in http://myserver/myteams/myprojects, the following
"breadcrumb" will be shown:
Mercurial > myteams > myprojects
Clicking on "myprojects" reloads the page. Clicking on "myteams" goes up one
folder. Clicking on the leftmost "Mercurial" goes to the server root.
This "breadcrumb" also appears on all repository pages. For example on the
summary page of the repository at http://myserver/myteams/myprojects/myrepo the
following will be shown:
Mercurial > myteams > myprojects > myrepo / summary
This change has been applied to all templates that already had a link to the
main repository page (i.e. gitweb, monoblue, paper and coal) plus to the index
page of the spartan template.
In order to make the breadcumb links stand out the some of the template styles
have been customized.
