A correct patch for this has existed in Python's BTS for 3 years
(http://bugs.python.org/issue9291), so waiting for it to be fixed
upstream is probably not a viable strategy. Instead, we add this
horrible hack to workaround the issue in existing copies of Python
2.4-2.7.
The search mode description can't be translated by itself, since
it's displayed as part of a template phrase (the "Assuming ..."
/ "Use ... instead" bits). Just drop the translation markers for
now, since the templates themselves currently do not support
translations.
This is the same thing which was done for changelog earlier, and it doesn't
affect performance at all. This change will make it possible to get the first
entry of the next page easily without computing the list twice.
The headers attribute is not initialized in certain error situations
(e.g. http 400 bad request). Check for self.headers before we attempt
to access 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.
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.
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.
