Some extensions set configuration settings that showed up in 'hg showconfig
--debug' with 'none' as source. That was confusing.
Instead, they will now tell which extension they come from.
This change tries to be consistent and specify a source everywhere - also where
it perhaps is less relevant.
Not all WSGI servers close the socket when an early response is sent
to a large POST request, which can cause the server to interpret the
already-sent request body as an incoming (but hopelessly invalid)
request.
Recreate the repo with the global configuration in repo.baseui. The repo
configuration is reread anyway. And now deleted repo configuration is reset to
the default value.
If exception is error.LookupError and running in i18n environment,
below condition is always true.
Because msg is translated and dosen't contain 'manifest'.
if util.safehasattr(err, 'name') and 'manifest' not in msg:
This patch creates a new exception class and uses it instead of
string match.
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.
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.
With the addition of the websub filter extension this extension is no longer
needed. We maintain a sort of backwards compatibility by reading the [interhg]
section and using it as we would use the [websub] section.
The purpose of this new filter is to make it possible to partially replace the
functionality of the interhg extension. The idea is to be able to define regular
expression based substitutions on a new "websub" config section. hgweb will then
be able to apply these substitutions wherever the "websub" filter is used on a
template.
This first revision just adds the code necessary to load the websub expressions
and adds the websub filter, but it does not add any calls to the websub filter
itself on any of the templates. That will be done on the following revisions.
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.
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.
This change complements the existing web/logourl setting, and lets the user
customize the logo image that is shown on many of the hg server pages.
If this setting is not set, hglogo.png is used.
By default, hgweb_mod supports caching via the ETag header. This can
cause some confusion with browsers which cache aggressively. This change
preserves existing behavior while giving the administrator a knob to
disable the ETag header.
Clicking on the logo image/text in the hgweb interface brings the
user to the Mercurial project page. The majority of users expect that
this would bring them to the top level index. I have added a new template
variable named `logourl' which allows an administrator to change this
behavior. To stay compatible with existing behavior, `logourl' will
default to http://mercurial.selenic.com/. This change is very useful in
large installations where jumping to the index is common.
Invalid requests could give an unhandled ErrorResponse.
Now this ErrorResponse is handled like other ErrorResponses so the client gets
an error message which also is logged on the server.
Without this fix, mod_wsgi and spawning get in a wedged state after
sending a 304 response. Not sending a body fixed that problem. The
header change was discovered by using wsgiref.validate.validator to
check for other errors.
The content type for both .tar.gz and .tar.bz2 downloads was
application/x-tar, which is correct for .tar files when no
Content-Encoding is present, but is not correct for .tar.gz and .tar.bz2
files unless Content-Encoding is set to gzip or x-bzip2, respectively.
However, setting Content-Encoding causes browsers to undo that encoding
during download, when a .gz or .bz2 file is usually the desired
artifact. Omitting the Content-Encoding header is preferred to avoid
having browsers uncompress non-render-able files.
Additionally, the Content-Disposition line indicates a final desired
filename with .tar.gz or .tar.bz2 extension which makes providing a
Content-Encoding header inappropriate.
With the current configuration browsers (Chrome and Firefox thus far)
are registering the application/x-tar Content-Type and not .tar
extension and appending that extension, yielding filename.tar.gz.tar as
a final on-disk artifact. This was originally reported here:
http://stackoverflow.com/questions/3753659
I've changed the .tar.gz and .tar.bz2 Content-Type values to
application/x-gzip and application/x-bzip2, respectively. Which yields
correctly named download artifacts on Firefox, Chrome, and IE.
getbundle(common, heads) -> bundle
Returns the changegroup for all ancestors of heads which are not ancestors of common. For both
sets, the heads are included in the set.
Intended to eventually supercede changegroupsubset and changegroup. Uses heads of common region
to exclude unwanted changesets instead of bases of desired region, which is more useful and
easier to implement.
Designed to be extensible with new optional arguments (which will have to be guarded by
corresponding capabilities).
Clients that send 100-continue should make sure they really support
continue intelligently. In a later patch we'll introduce a capability so
new clients don't pay a performance penalty talking to old servers.
