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.
Up until now the templates that show RSS and Atom feeds on the "repository
lists" (i.e. gitweb and monoblue) showed them for all entries, including regular
folders. Clicking on those "folder RSS" links would result in an error page
being shown.
This patch hides those links for regular folders.
During merge of branches, it is useful to compare merge results against
the two parents. This change adds this support to hgweb. To specify
which parent to compare to, use rev/12300:12345 where 12300 is a
parent changeset number. Two links are added to changeset web page so
that one can choose which parent to compare to.
Currently when obtaining an archive snapshot of a repository via the
web interface, subrepositories are not taken in the snapshot. I
introduce an option, archivesubrepos, which allows this.
It's preferable to report "ssl required" as an error, so that the client
can detect error and exit with 255. Currently hg exits with 1, which is
"nothing to push."
This makes the 'additional help topics' list consistent with the output from
keyword search (for instance subrepo/subrepos).
The sorting by longest name was introduced in 4cbe49492ad3. There might have
been a good reason for it back then, but now it seems like a better idea to
place the preferred name first in the list in helptable.
- Fix off-by-one error on displayed entries count in normal mode
- Fix incorrect paging when the top revision was lower than revcount
- Fix revcount not overriding web.maxshortchanges everywhere
Previously, the parents / children were computed relative to the cset of the
currently shown file, which was wrong and inconsistent with diff and others.
With this patch, the listed csets are those that contain changes to the
currently compared file, which don't necessarily have to be the direct parents
and children of the changeset itself.
The top-level 'comparison' template was not really needed, and it also caused a
traceback to be shown for inexistent files (as reported by Ross Lagerwall).
Getting rid of it makes the overall templating structure simpler and causes
invalid files to be handled nicely.
Previously, browsing to http://serv/diff would generate an internal
server error due to the file and node parameters being missing.
The same error also occurred for filelog, comparison and annotate.
Adds new web command to the core, ``comparison``, which enables colorful
side-by-side change display, which for some might be much easier to work with
than the standard line diff output. The idea how to implement comes from the
SonicHq extension.
The web interface gets a new link to call the comparison functionality. It lets
users configure the amount of context lines around change blocks, or to show
full files - check help (also in this changeset) for details and defaults. The
setting in hgrc can be overridden by adding ``context=<value>`` to the request
query string. The comparison creates addressable lines, so as to enable sharing
links to specific lines, just as standard diff does.
Incorporates updates to all web related styles.
Known limitations:
* the column diff is done against the first parent, just as the standard diff
* this change allows examining diffs for single files only (as I am not sure if
examining the whole changeset in this way would be helpful)
* syntax highlighting of the output changes is not performed (enabling the
highlight extension has no influence on it)
The existing help only walked through an example.
Now we first explain the basic rules and then show an example.
The 'collections' example and description only cause confusion and is removed.
Bikeshedded by Patrick Mezard <patrick@mezard.eu>
Previously, graph data has been encoded for processing done by
JavaScript code run in the browser, employing simple structures
with implicit member positions. This patch modifies the graph
command to also produce data employing a dictionary-based
structure suitable for use with the templating mechanism, thus
permitting other ways of presenting repository graphs using that
mechanism.
In order to test these changes, the raw theme has been modified
to include templates for graph nodes and edges. In a similar
fashion, themes could employ technologies such as SVG that lend
themselves to templating to produce the graph display. This patch
makes use of a much simpler output representation than SVG in
order to maintain clarity.
Previously, we were finding the most recent version of a file in a
changeset and comparing it against its first file parent. This was
wrong on three counts:
- it would show a diff in revisions where there was no change to a file
- it would show a diff when only the exec bit changed
- it would potentially compare against a much older changeset, which
could be very expensive if git-style rename detection was enabled
This compares the file in the current context with that context's
parent, which may result in an empty diff when looking at a file not
touched by the current changeset.
in hgweb help top page, help topics are localized, but abstracts of
commands and extensions are not, although these are already
translated.
it is because localized messages for them should be explicitly looked
up by original ones.
this patch looks localized messages up for each commands/extensions.
The changeset view may show several diff regions, one per file, and this patch
numbers each of them so that links produced by the filenodelink fragment can
reference each diff region produced by the diffblock fragment through the use
of the blockno variable made available to both of them. This permits
navigation to diff regions on the changeset page from the file list, and
where the :target pseudo-class is supported in browsers, permits selective
presentation of diffs, showing one at a time instead of potentially many in
what would otherwise be a very long page that is difficult to navigate.
The descend option in hgweb can be used to display all reachable repositories
within a directory hierarchy if set to True. However, all reachable
repositories, regardless of their depth below the root of the hierarchy, are
then listed at the same level - expanded - in the hgweb interface. This patch
adds support for showing only each level of a directory hierarchy, with
subrepositories being shown alongside their parent repositories only at the
appropriate level (because there is no way to navigate to subrepositories from
within repositories), and the contents of directories hidden - collapsed -
behind a link for each directory. To enable this multi-level navigation, a new
option called collapse must be set to True when the descend option is set to
True.
You can specify width to visually distinguish main branch (trunk)
on hgweb's graph page. Settings format is branch_name.width = value,
where width in px e.g.:
[graph]
default.width = 3
some problematic encoding (e.g.: cp932) uses ASCII alphabet characters
in byte sequence of multi byte characters.
"str.lower()" on such byte sequence may treat distinct characters as
same one, and cause unexpected log matching.
this patch uses "encoding.lower()" instead of "str.lower()" to
normalize strings for compare.
splitblock() was added to handle blocks returned by bdiff.blocks() which differ
only by blank lines but are not made only of blank lines. I do not know exactly
how it could happen but mdiff.blocks() threshold behaviour makes me think it
can if those blocks are made of very popular lines mixed with popular blank
lines. If it is proven to be wrong, the function can be dropped.
The first implementation made annotate share diff configuration entries. But it
looks like users will user -w/b for annotate but not for diff, on both the
command line and hgweb. Since the latter cannot use command line entries, we
introduce a new [annotate] section duplicating the diff whitespace options.
Older clients will still print the provided error message and not much else:
over ssh, this will be each line prefixed with 'remote: ' in addition to an
"abort: unexpected response: '\n'"; over http, this will be the '---%<---'
banners in addition to the 'does not appear to be a repository' message.
Currently, clients with this patch will display 'abort: remote error:\n' and
the provided error text, but it is trivial to style the error text however is
deemed appropriate.
Before: hgweb made it possible to download file content with a content type
detected from the file extension. It would serve .html files as text/html and
could thus cause XSS vulnerabilities if the web site had any kind of session
authorization and the repository content wasn't fully trusted.
Now: all files default to "application/binary", which all important
browsers will refuse to treat as text/html. See the table here:
https://code.google.com/p/browsersec/wiki/Part2#Survey_of_content_sniffing_behaviors
In the branches page, branches that are closed and are merged into another
branch are displayed as `inactive'. This patch changes that behaviour to
show these branches as `closed'.
For me, the `closed' attribute is more important than the `inactive'
attribute.
Branches that are not closed, and are merged into other branches will still
be shown as `inactive'.
Branches that are closed, and are not merged into other branches will still
be shown as `closed'.
This is the same message displayed at the end of the "diff --stat" command.
For example, "9 files changed, 1651 insertions(+), 2 deletions(-)".
The webutil.diffstatgen function allows the diffstat data to be lazily
calculated only once and then re-used.
This allows the diffstat templates to link into the diff output. For example,
the URLs of the first three files within the diff are #l1.1, #l2.1, #l3.1.
The webutil.diffstat function now returns a diffstat template for each file
in the diff. It previously returned a template for each file returned by
ctx.files() which did not work well for merge changesets.
Remove the lambda used to wrap webutil.diffstat because:
- functions passed to the templater must accept keyword arguments
- webutil.diffstat is a generator, so already calculates the diffstat lazily
This reverts the changes made to a4067e29e29d after it was submitted to the
mailing list but before it was queued.
This includes all affected files, so it can be used for an extended view of
the files or as a replacement for the filenodelink and filenolink templates.
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.
Send the command arguments in the HTTP headers. The command is still part
of the URL. If the server does not have the 'httpheader' capability, the
client will send the command arguments in the URL as it did previously.
Web servers typically allow more data to be placed within the headers than
in the URL, so this approach will:
- Avoid HTTP errors due to using a URL that is too large.
- Allow Mercurial to implement a more efficient wire protocol.
An alternate approach is to send the arguments as part of the request body.
This approach has been rejected because it requires the use of POST
requests, so it would break any existing configuration that relies on the
request type for authentication or caching.
Extensibility:
- The header size is provided by the server, which makes it possible to
introduce an hgrc setting for it.
- The client ignores the capability value after the first comma, which
allows more information to be included in the future.
The introduction of the new URL parsing code has created a startup
time regression. This is mainly due to the use of url.hasscheme() in
the ui class. It ends up importing many libraries that the url module
requires.
This fix helps marginally, but if we can get rid of the urllib import
in the URL parser all together, startup time will go back to normal.
perfstartup time before the URL refactoring (707e4b1e8064):
! wall 0.050692 comb 0.000000 user 0.000000 sys 0.000000 (best of 100)
current startup time (9ad1dce9e7f4):
! wall 0.070685 comb 0.000000 user 0.000000 sys 0.000000 (best of 100)
after this change:
! wall 0.064667 comb 0.000000 user 0.000000 sys 0.000000 (best of 100)
