This makes it possible to make keyword search in case the search query also
specifies an exact revision (like '1234' or 'abcdef'), or a revset expression.
Get the whole list of entries before rendering instead of using lazy evaluation.
This doesn't affect the performance for usual case when the entries are shown
anyway. When both entries and latestentry are used, this performs unnoticeably
faster, and for pages which use only latestentry (quite uncommon case) it
would be a bit slower.
This change will make it possible to get the first entry of the next page easily
without computing the list twice.
This mode is used when all the conditions are met:
- 'reverse(%s)' % query string can be parsed to a revset tree
- this tree has depth more than two, i.e. the query has some part of
revset syntax used
- the repo can be actually matched against this tree, i.e. it has only existent
function/operators and revisions/tags/bookmarks specified are correct
- no revset regexes are used in the query (strings which start with 're:')
- only functions explicitly marked as safe in revset.py are used in the query
Add several new tests for different parsing conditions and exception handling.
This changes the behavior for queries which point at a revision directly,
now the output is consistent to other cases: it results in only this matched
revision shown, not the log starting with it.
A new test checks this behaviour and fails for the old one.
This changes makes clearer which arguments can a function depend on. Now all
the modified functions depend on the 'query' argument only, but future additions
will change it.
Given that N is maximum revision number in a repo, than if a revision with
number N-100n or N-100n+1 (for any integer n) is found with a hgweb search,
this revision is duplicated in search results.
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.
Actual amount of revisions is used now instead of their numbers in the repo
before to deal with skipped numbers correctly.
This iterates starting from the newest revision (which is shown on top)
yielding up to the specified count, instead of the reversed order used before.
Effect of this change on efficiency is negligible, when the same changesets are
returned.
It is the same fix for graph command, as was recently for log. This makes the
specified revision be always on top of the graph view.
Before the patch, for example with repo having revisions 0, 1, 2, 3 and revision
in url being '2', all revisions were shown and the specified one wasn't
the first.
This makes the specified revision be always on top of the list.
Before the patch, for example with repo having revisions 0, 1, 2, 3 and user
searching for '2', all revisions were shown and the specified one wasn't
the first.
Before this when multiple changesets hashes in the repos started with the
search query string, error was given that the revision isn't found, and it
was misleading. Now a simple keyword search runs in this case.
Before this changeset, navigation generation crashed if revision "0" was
filtered. We introduce a `_first` methods on revision navigation that return the
lowest unfiltered element and use it in two place were the "0" changeset was
explicitly referenced.
Test case are introduced.
For some obscure reason, changelog.node(0) returns nullid if changelog is empty.
this break empty navigation detection. We fix this code by using the length of
the changelog.
Using the length have some issue with revision filtering but this is a small
step in the right direction. Proper fix comes in later changeset.
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.
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.
The archive web command now takes into account the "file" request entry, if one
is provided.
The provided "file" is processed as a "path" corresponding to a directory or
file that will be downloaded.
With this change hgweb can to process requests such as:
http://mercurial.selenic.com/hg/archive/tip.zip/mercurial/templates
This will download all files on the mercurial/templates directory as a zip file.
It is not possible to specify file patterns ('glob', 'relglob', 'path',
'relpath', 're', 'relre' nor 'set'). The server will reject those with a
403 HTTP error response.
Note that this is a first step to add support for downloading directories from
the web interface. A following patch will modify the archiveentry map entry on
the different templates so that it adds the current folder path to the archive
links.
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.
