One of the features of hgweb is that current position in repo history is
remembered between separate requests. That is, links from /rev/<node_hash> lead
to /file/<node_hash> or /log/<node_hash>, so it's easy to dig deep into the
history. However, such links could only use node hashes and local revision
numbers, so while staying at one exact revision is easy, staying on top of the
changes is not, because hashes presumably can't change (local revision numbers
can, but probably not in a way you'd find useful for navigating).
So while you could use 'tip' or 'default' in a url, links on that page would be
permanent. This is not always desired (think /rev/tip or /graph/stable or
/log/@) and is sometimes just confusing (i.e. /log/<not the tip hash>, when
recent history is not displayed). And if user changed url deliberately to say
default instead of <some node hash>, the page ignores that fact and uses node
hash in its links, which means that navigation is, in a way, broken.
This new property, symrev, is used for storing current revision the way it was
specified, so then templates can use it in links and thus "not dereference" the
symbolic revision. It is an additional way to produce links, so not every link
needs to drop {node|short} in favor of {symrev}, many will still use node hash
(log and filelog entries, annotate lines, etc).
Some pages (e.g. summary, tags) always use the tip changeset for their context,
in such cases symrev is set to 'tip'. This is needed in case the pages want to
provide archive links.
highlight extension needs to be updated, since _filerevision now takes an
additional positional argument (signature "web, req, tmpl" is used by most of
webcommands.py functions).
More references to symbolic revisions and related gripes: issue2296, issue2826,
issue3594, issue3634.
Surpringly, the templates didn't receive an unmodified version of the
line numbers. Expose it to make implementing the JSON templates easier.
In theory, we could post-process an existing template variable. But
extra string manipulation seems quite wasteful, especially on items that
could occur hundreds or even thousands of times in output.
It's pretty surprising phase wasn't part of this template call already.
We now expose {phase} to the {changeset} template and we expose this
data to JSON.
This brings JSON output in line with the output from `hg log -Tjson`.
The lone exception is hweb doesn't print the numeric rev. As has been
stated previously, I don't believe hgweb should be exposing these
unstable identifiers. (We can add them later if we really want them.)
There is still work to bring hgweb in parity with --verbose and
--debug output from the CLI.
Although Python supports `X = Y if COND else Z`, this was only
introduced in Python 2.5. Since we have to support Python 2.4, it was
a very common thing to write instead `X = COND and Y or Z`, which is a
bit obscure at a glance. It requires some intricate knowledge of
Python to understand how to parse these one-liners.
We change instead all of these one-liners to 4-liners. This was
executed with the following perlism:
find -name "*.py" -exec perl -pi -e 's,(\s*)([\.\w]+) = \(?(\S+)\s+and\s+(\S*)\)?\s+or\s+(\S*)$,$1if $3:\n$1 $2 = $4\n$1else:\n$1 $2 = $5,' {} \;
I tweaked the following cases from the automatic Perl output:
prev = (parents and parents[0]) or nullid
port = (use_ssl and 443 or 80)
cwd = (pats and repo.getcwd()) or ''
rename = fctx and webutil.renamelink(fctx) or []
ctx = fctx and fctx or ctx
self.base = (mapfile and os.path.dirname(mapfile)) or ''
I also added some newlines wherever they seemd appropriate for readability
There are probably a few ersatz ternary operators still in the code
somewhere, lurking away from the power of a simple regex.
Similar in spirit to df435ff00d29, I want to write an extension to
make available extra template keywords so hgweb templates can include
extra data.
To do this today requires monkeypatching the templater, which I think is
the wrong place to perform this modification.
This patch extracts the creation of the templater arguments to a
standalone function - one that can be monkeypatched by extensions.
I would very much like for extensions to be able to inject extra
templater parameters into *any* template. However, I'm not sure the best
way to facilitate this, as hgweb commands invoke the templater before
returning and we want the extensions to have access to rich data
structures like the context instances. We need cooperation inside hgweb
command functions. The use case screams for something like internal-only
"hooks." This is exactly what my (rejected) "events" patch series
provided. Perhaps that feature should be reconsidered...
The issue is titled "filtered revision 'XXX' (not in 'served' subset)" and that
is the error message you sometimes get when trying to look at a file (/file or
/annotate) in hgweb. For example:
http://hg.intevation.org/mercurial/crew/file/8414f8487b33/mercurial/cmdutil.py
This happens when a parent revision for a file is hidden, thus it is
not 'served' and isn't accessible in hgweb by default. When hgweb tries to
access such changeset, it produces the error and HTTP status code 404.
Another detail is that the parents() function, that is used in multiple places
in hgweb, sometimes returned changesets that were obsoleted by the current
changeset for the file. For example, when using rebase with evolve and rebasing
a divergent changeset that introduces a file on top of current branch. Or
grafting a change and making the new grafted changeset obsolete the source
(shown in the test case). The result is the same - the obsoleted changeset was
mistakingly returned from parents(), even though it's not a parent and the only
link to the new changeset is an obsoletion marker (and rebase/graft metadata?
not sure it matters).
The problem is fixed by using introrev() instead of linkrev() for finding
parents. This prevents parents() function from returning unrelated obsolete
changesets.
The test case prepares a separate repo because (afaict) all other test cases
never reuse file names, so there are no files that were changed in multiple
changesets. So no previously available files have obsolete changesets in their
history.
I want to supplement changelist entries (used by shortlog and changelog
endpoints) with custom metadata from an extension. i.e. I have extra
per-changeset metadata that I wish to make available to templates so it
can be rendered on hgweb.
To facilitate this, I've extracted the logic for creating a changeset
data structure into its own function, where it can be wrapped by
extensions.
Ideally, hgweb would use the same templater as the command line and have
full access to templatekw.keywords. But that's a lot of work. This patch
gets us some of the benefit without all the work.
Many other hgweb commands could benefit from similar refactorings. I'm
going to wait to see how this patch is received before I go crazy on
extracting inline functions.
Before this patch, "parents" in pages for file doesn't show as same
parents as "hg parents -r REV FILE", when the specified file is not
modified in the specified revision.
For example, it is assumed that revision A, B and D change file "f".
changelog (A) ---> (B) ---> (C) ---> (D)
filelog "f" (x) ---> (y) ------------> (z)
"/file/D/f" invokes "webutil.parents()" with filectx(z) gotten from
changectx(D), and it returns changectx(B). This is as same result as
"hg parents -r D f".
In the other hand, "/file/C/f" invokes "webutil.parents()" with
filectx(y') gotten from changectx(C), and it returns changectx(A),
because filectx(y') is linked to changectx(B), and works like
filectx(y) in some cases.
In this case, revision B is hidden from users browsing file "f" in
revision C.
This patch shows as same parents as "hg parents -r REV FILE" in pages
for file, by making "webutil.parents()" return:
- "linkrev()"-ed revision only, if:
- specified context instance is "filectx" (because
"webutil.parents()" is invoked with changectx, too), and
- (1) the revision from which filectx is gotten and (2) the one to
which filectx is linked are different from each other
- revision gotten from "ctx.parents()", otherwise
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.
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)
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.
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 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.
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.
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.
