Before this patch, each log entries in "changelog" and "revisions"
pages of "spartan" style are not aligned by column, because:
- each log entries are separated "<table>" entries, and
- there are no fixed "width" information for each "<th>"/"<td>" entries
This patch aligns entries in "changelog" and "revisions" pages of
"spartan" style by:
- adding 'label' class to '<th>' for 'age' information, and
- setting 'width' of '<th class="label">' with fixed size
'class="age"' is not used for this purpose, because it is also used to
set "bold" font-weight
"16em" seems to be wide enough to show date information fully, when
web browser disables (or doesn't support) javascript.
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
This patch also fixes same problem of "coal" style, because it re-uses
"filerevision.tmpl" of "paper" style.
"gitweb" and "monoblue" styles don't have such problems.
"spartan" style doesn't have "bookmarks" page definition itself.
For example, this is useful for linking from the feed reader to a bug tracker.
This follows the existing pattern used within the hgweb templates. With the
exception of the raw style, all usages of the changeset "desc" keyword are now
followed by either the "firstline" filter or the "websub" filter. When "websub"
is used, it always follows the "escape" filter.
Namely, this allows the next page pointer to be not only revision hash given
in page code, but also any value computed from the value for previous page.
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.
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.
The -a option to GNU grep isn't available when using Solaris grep. Replace
the one use of grep -a in the testsuite with some in-line Python that does
the equivalent, and add a check for grep -a in check-code.py.
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.
This gives all the benefits introduced before for file source view, namely
code selection without line numbers and correct indents, highlighting line
which is linked to, long lines wrapping.
Implementation strategy is also the same as for file source view: all the
lines are put in a sigle pre tag with span's for each line. Correct line
numbering (same as before this patch) is achieved with nested CSS counters.
Introduce stripes2 and stripes4 classes to support different structure.
They will be useful to implement stripes with pure CSS everywhere instead
of current server-side implementation.
This uses classList property, which is well-supported now: both Chromium 8.0+,
Firefox 3.6+ and Opera 11.5+ support it, as well as relatively modern versions
of other browsers.
All the source lines are put in a <pre> tag, which gives correct display and
copy&paste in both Chromium (WebKit) and FireFox: line numbers are not copied,
all the tabs and spaces are kept. This doesn't change the visual appearance
of the view compared to current hgweb version and doesn't use any JS code.
Also, stripes in this view are now generated clientside with CSS.
This implementation is chosen because other variants have important issues:
Strategy FF Chrome
current D,LT,E,T,L D,L
pre S,NW S,NW
pre/div/nbsp LT,E,T,TS,NW TS,NW
pre/div/br LT,E,T,NW NW
ol/li/nbsp LT,E,T,TS,AJ TS,AJ
ol/li/br LT,E,T,AJ AJ
pre/span LV LV
Legend
Strategies:
- current: implemented in hgweb before this patch, i.e. divs for each line,
and line numbers links in the div too
- pre: the whole code in one pre tag with newlines, all line numbers
in another one with 'float: left'
- pre/div/{nbsp,br}: same as just 'pre', but separate divs for each line and
or <br> instead of empty lines (otherwise they are not copied at all)
- ol/li/{nbsp,br}: a single ol with li's and divs for each line,
or <br> same as in previous strategy
- pre/span: this patch
Problems:
D = (very minor) display problems, like wrong width of leading tabs
LT = loses leading/trailing whitespace
E = loses embedded whitespace
B = loses blank lines
T = loses tabs
L = selects line numbers
LV = (only) visually selects line numbers
LVE = (only) visually selects line numbers at empty lines
S = no stripes (and no ability to easily highlight
lines-which-are-linked-at in the future)
TS = space copied instead of empty line
AJ = get anchor links only with JS (they work even without)
NW = no linewrap easily possible (in future)
As for browser versions compatibility, the CSS tricks used are supported in
(according to caniuse.com):
a) line numbers generation with 'content:' property and CSS counters:
IE 8+, all other popular browsers (in pre-WebKit Opera numbers are being copied)
b) stripes ('nth-child' selector):
IE 8+, FF 3.5+, Safari 3.2+, Opera 9.5+, all other popular browsers
c) line numbers are not visually selected ('user-select:' property):
IE 10+, Opera 15.0+, all other popular browsers
This patch is based on a demo implementation by
Martin Geisler <martin@geisler.net>.
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.
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.
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 user interface introduced in 3ff83729b63f is not considered ready
for prime time yet. The internal code stays in place for custom template
usage. The feature is ultimately wanted and will be re-enabled soon. The
current issue is only related to the visual of the current interface.
Don't expose unserved changesets to remote repos. Thanks to Sean Farley
<sean.michael.farley@gmail.com> for tracking down the issue and
Pierre-Yves David <pierre-yves.david@ens-lyon.org> for the fix.
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.
str.splitlines could not be used in 2d839579ce70, but _now_ we would like to
have lines with other line endings than \n.
Some fine occurences of (esc) markup of \r is replaced with multiple lines
ending with '\r (no-eol) (esc)'. That is no win but also no significant loss.
This change makes it possible to drop filtercr.py - _that_ is a win.
