Summary:
These tests use hard coded url's that don't include bundlecaps, so it's
difficult to convert them to use the right bundlecaps for bundle2.
Reviewed By: quark-zju
Differential Revision: D7591165
fbshipit-source-id: 3424c448be8c713cac5b876438745414a59b7230
Summary:
When running with a Python runtime with a slightly different zlib module,
some `zlib.compress` outputs are different. Some tests are testing the
length, or the content of `zlib.compress` output, directly or indirectly.
That's causing issues.
This patch adds a `common-zlib` hghave test so it can be used to gate tests
checking zlib output. Some lengths are also changed to glob patterns to be
compatible.
Reviewed By: ryanmce
Differential Revision: D6937735
fbshipit-source-id: 2328a39d7f2022f16d51f61b6178568b26dfe2fb
Summary:
Previously `hg server` uses `HGPORT` that might be in use. This patch uses
`-p 0 --port-file ...` so `hg server` always gets assigned a free port.
The change was first made by the following Ruby script:
```
re = /^ \$ hg serve(.*) -p \$(HGPORT[12]?) (.*[^\\])$\n \$/
Dir['*.t'].each do |path|
old = File.read(path)
new = old.lines.map do |l|
next l if l[/\(glob\)/] or not l['$HGPORT'] or l[/^ [$>]/]
"#{l.chomp} (glob)\n"
end.join.gsub re, <<-'EOS'.chomp
$ hg serve\1 -p 0 --port-file $TESTTMP/.port \3
$ \2=`cat $TESTTMP/.port`
$
EOS
File.write(path, new) if old != new
end
```
Then there are some manual changes:
run-tests.py: It now treats `$HGPORT` in output as glob pattern `*`, since
it does not know the assigned value in tests.
test-bookmarks-pushpull.t, test-https.t: Some `hg pull`s were changed to use
explicit paths instead of relying on `.hgrc` since the test restarts the
server and `.hg/hgrc` having an outdated URL.
test-schemes.t: The test writes `$HGPORT` to `.hgrc` before assigning it.
Changed the order so the correct `$HGPORT` is written.
test-patchbomb-tls.t: Changed `(?) (glob)` to `(glob) (?)`.
Reviewed By: DurhamG
Differential Revision: D6925398
fbshipit-source-id: d5c10476f43ce23f9e99618807580cf8ba92595c
Summary: Also change the internal API so it no longer accepts the "heads" argument.
Reviewed By: ryanmce
Differential Revision: D6745865
fbshipit-source-id: 368742be49b192f7630421003552d0a10eb0b76d
Once upon a time, in 1995, there were browsers that didn't understand <script>
tags and they would simply show the code inside as text. This started a
tradition of wrapping everything inside <script> in <!-- HTML comments -->.
Nowadays, it's not only not needed, but can be considered harmful[1]:
- within XHTML documents, the source will actually be hidden from all browsers
and rendered useless
- `--` is not allowed within HTML comments, so any decrement operations in
script are invalid
[1]: http://www.javascripttoolbox.com/bestpractices/#comments
Previously, when user scrolled down to see the next page on /graph, all hgweb
did was re-render everything that would be visible (by simply incrementing
revcount). It was not efficient at all, and this patch makes /graph page behave
similarly to the regular /log: every new page only consists of new changesets,
no duplication, and only jsdata is based on the full set of changesets required
to build accurate graph.
This is achieved by adding "?graphtop=<node>" to the next page URL template,
effectively remembering where the graph started, and using that value to create
the new `tree` that covers the whole visible graph. That variable is then used
to produce jsdata for redrawing graph client-side.
nextentry is used for the same purpose as on /log page (to format the next page
URL), but it's not a part of the graph.
hgweb determines and passes to templates some variables related to graph
appearance, like bg_height, canvaswidth and canvasheight. bg_height was and
still is used for graph.scale() call in graph.tmpl, and the two latter
variables were used in <canvas> element as width and height properties, and
they were set before JS code got to run. Setting these properties server-side
doesn't make a lot of sense, because a graph that has been scaled should
calculate things like width and height on its own when being rendered.
Let's move (re)sizing <canvas> to JavaScript (to Graph.render function) and
stop parsing HTML with regular expressions just to know new width and height.
That extra loop that only counts cols is required because <canvas> can't
be resized after or in the process of rendering (or it gets cleared).
Incidentally, SVG doesn't have this problem and I'm hoping to switch graph to
using it in future.
There also was truecanvasheight, but according to hg grep --all it was never
used, see f5506d2a674c.
Just to give some context to the return values: vertex() needs to return two
HTML elements as strings, <li> to be used as a background and a <li> to be
shown in foreground. The latter was made obsolete recently when changesets
started to be rendered server-side, but background elements are still useful
for now.
When we replaced the patterns, glob was removed on the fixed line, it was a
mistake and caused the pure-only build to fails.
Differential Revision: https://phab.mercurial-scm.org/D1592
Historically, client-side graph code was not only rendering the graph itself,
but it was also adding all of the changeset information to the page as well.
It meant that JavaScript code needed to construct valid HTML as a string
(although proper escaping was done server-side). It wasn't too clunky, even
though it meant that a lot of server-side things were duplicated client-side
for no good reason, but the worst thing about it was the data format it used.
It was somewhat future-proof, but not human-friendly, because it was just a
tuple: it was possible to append things to it (as was done in e.g.
4d7cfa1867b5), but you'd then have to remember the indices and reading the
resulting JS code wasn't easy, because cur[8] is not descriptive at all.
So what would need to happen for graph to have more features, such as more
changeset information or a different vertex style (branch-closing, obsolete)?
First you'd need to take some property, process it (e.g. escape and pass
through templatefilters function, and mind the encoding too), append it to
jsdata and remember its index, then go add nearly identical JavaScript code to
4 different hgweb themes that use jsdata to render HTML, and finally try and
forget how brittle it all felt. Oh yeah, and the indices go to double digits if
we add 2 more items, say phase and obsolescence, and there are more to come.
Rendering vertex in a different style would need another property (say,
character "o", "_", or "x"), except if you want to be backwards-compatible, it
would need to go after tags and bookmarks, and that just doesn't feel right.
So here I'm trying to fix both the duplication of code and the data format:
- changesets will be rendered by hgweb templates the same way as changelog and
other such pages, so jsdata won't need any information that's not needed for
rendering the graph itself
- jsdata will be a dict, or an Object in JS, which is a lot nicer to humans and
is a lot more future-proof in the long run, because it doesn't use numeric
indices
What about hgweb themes? Obviously, this will break all hgweb themes that
render graph in JavaScript, including 3rd-party custom ones. But this will also
reduce the size of client-side code and make it more uniform, so that it can be
shared across hgweb themes, further reducing its size. The next few patches
demonstrate that it's not hard to adapt a theme to these changes. And in a
later series, I'm planning to move duplicate JS code from */graph.tmpl to
mercurial.js and leave only 4 lines of code embedded in those <script>
elements, and even that would be just to allow redefining graph.vertex
function. So adapting a custom 3rd-party theme to these changes would mean:
- creating or copying graphnode.tmpl and adding it to the map file (if a theme
doesn't already use __base__)
- modifying one line in graph.tmpl and simply removing the bigger part of
JavaScript code from there
Making these changes in this patch and not updating every hgweb theme that uses
jsdata at the same time is a bit of a cheat to make this series more
manageable: /graph pages that use jsdata are broken by this patch, but since
there are no tests that would detect this, bisect works fine; and themes are
updated separately, in the next 4 patches of this series to ease reviewing.
"top: -Xpx" shifts a block up by X pixels, which can be used to visually
compress two lines of text to have less space between them, in this case it's
used for the changesets on /graph page. But not only it's not needed there
(both lines fit fine into their allowed vertical space), but it would also look
better (not as crammed, more vertically centered) without these negative
values.
"position: relative" is needed solely for the "top" property to have effect on
the element, no children of the .info element rely on it, so let's remove it as
well.
Variables that are used or assigned without any declaration using var (or let,
or const) are considered global. In many cases this is inadvertent and actually
causes a variable leaking to a broader scope, such as a temporary variable used
inside a loop suddenly being accessible in global scope. (This corresponds to
"undef" option of jshint).
So this patch limits the scope of variables that don't need to be global. There
are a lot of helper variables in Graph.render() used in a loop, I've declared
them all on one line to reduce patch size. "radius" is special because it
wasn't passed to graph.vertex, but was used there (it worked because this
variable leaked to global scope). "window.graph" is created by an inline script
in graph.tmpl so that it can be used in ajaxScrollInit() function, this patch
makes this fact explicit by assigning window.graph to a local variable.
The original tests (kanji and null) in test-hgweb-commands.t come from
6213c4c3d3f7 and f18359d4ac5a, but they check json escape filter by using
JavaScript variable on /graph page, which is awkward, and I'm planning to
remove commit description from this variable soon. Let's move the parts that
check json template filter to a more appropriate file and use normal json-*
templates.
mercurial.js has a process_dates() function that calculates relative age for a
given date, it works for all elements with "age" css class. If those elements
also have "date" css class, the original text is preserved and age is added at
the end.
This patch adds these two css classes in some pages in gitweb and monoblue that
weren't already using this feature.
In spartan theme phase is shown on its own table row, because there's no single
line of "tags". Everywhere else phase is prepended to the list of "tags" of a
changeset. Its element has a purple-ish color in gitweb and monoblue, and a
dotted line under it and no color in paper and coal (as these themes are frugal
with colors).
This patch intentionally doesn't touch graph, because it needs a rewrite. I'll
get to it pretty soon and in the process will add phase and everything that's
still coming (e.g. obsolescence and instabilities).
.. feature::
hgweb now displays phases of non-public changesets
This patch puts all these changeset "tags" into one template shared everywhere
in paper and coal themes. But it should be noted that some of the templates had
different sets of tags, in some cases it was intended, in others - most likely
not.
First, what's up with all these different ways to get changeset's branch. There
are actually 3 ways to do it in hgweb, they can all be seen in this patch;
"branches", "inbranch" and "branch". They are all lists that consist of 1 or 0
items:
- "branches" has ctx.branch() if current changeset is the tip of that branch
- "inbranch" has ctx.branch() if current changeset is _not_ the tip of that
branch and the branch is not "default"
- "branch" aka "changesetbranch" has ctx.branch() if the branch is not
"default"
The majority of cases (7 vs 2 + /graph) in paper theme used only option 3,
which meant that "default" was never displayed. But other parts of the theme
disagreed with this and used option 1 and option 2 together. For example, the
default view (log) displays "default" on the branch tip (can be seen right
about now on m-s.o/repo/hg), but it disappears when you click on the commit.
Also, using option 3 alone meant that there was no way to tell if a changeset
is the tip of its branch or not (it was always assumed that it's not, see how
some css classes change from "branchname" to the correct "branchhead" in tests)
-- so the two different css styles that exist in paper just for this were
underused.
I think this patch improves the situation, even though it changes the old (even
if inconsistent) behavior. The new behavior matches that of gitweb and
monoblue.
Specifically, zstd isn't available in --pure mode, and we need to glob
off the leading comma as well as the absent compression engine.
Differential Revision: https://phab.mercurial-scm.org/D859
A new bundle2 capability 'phases' has been added. If 'heads' is part of the
supported value for 'phases', the server supports reading and sending 'phase-
heads' bundle2 part.
Server is now able to process a 'phases' boolean parameter to 'getbundle'. If
'True', a 'phase-heads' bundle2 part will be included in the bundle with phase
information relevant to the whole pulled set. If this method is available the
phases listkey namespace will no longer be listed.
Beside the more efficient encoding of the data, this new method will greatly
improve the phase exchange efficiency for repositories with non-served
changesets (obsolete, secret) since we'll no longer send data about the
filtered heads.
Add a new 'devel.legacy.exchange' config item to allow fallback to the old
'listkey in bundle2' method.
Reminder: the pulled set is not just the changesets bundled by the pull. It
also contains changeset selected by the "pull specification" on the client
side (eg: everything for bare pull). One of the reason why the 'pulled set' is
important is to make sure we can move -common- nodes to public.
These are some simple cases. More to come in a future change.
Reviewers: krbullock
Reviewed By: krbullock
Differential Revision: https://phab.mercurial-scm.org/D4
While plugging followlines.js into "annotate" view, we'll need to walk a
different DOM structure from that of "filerevision" view. In particular, the
selectable source line element is a <tr> in annotate view (in contrast with a
<span> in filerevision view). So make this tag name a parameter of
followlines.js script by passing its value as a "selectabletag" data attribute
of <pre class="sourcelines"> element.
As <pre class="sourcelines"> tags are getting quite long in templates, rewrite
them on several lines.
c0593b622180 changed the styling of the "page_nav" CSS class to use
flexbox to separate elements within the <div>. I didn't realize that
this class was used outside of the links in the header. So this
resulted in incorrectly formatting links in the footer of various
pages. Fix that by introducing a new CSS class that preserves the
old CSS behavior.
gitweb was missing the hint hover box. So that was added.
Also, the positioning of the form was absolute and it didn't
vertically align on all pages. The element has been moved inline
with the navigation links (which now are contained in a div) and
flexbox is used to obtain sane alignment of the navigation links
and search form. For those new to flexbox,
"justify-content: space-between" basically says to maximize space
elements. You can use it to easily get left and right justified
containers without having to worry about width, floating, etc.
"align-items: center" centers all items in a cross-axis. I've
literally wasted hours trying to figure out both these problems
before flexbox. Flexbox is amazing.
Flexbox has been supported by Chrome and Firefox for a few years.
But it is only supported by IE 11. I'm willing to wager that
people using this either won't be using IE or will be using IE 11.
So I'm willing to be a bit aggressive in adopting flexbox because
it makes CSS alignment so much easier.
Paper has it on all pages. Not sure why gitweb doesn't. I think it
should be everywhere because it is a useful feature.
Also, we weren't consistently adding the HTML in the same place. This
was OK since the element is absolutely positioned. But this bothered
me a bit, so I went ahead and fixed it.
AFAICT this was mostly a bunch of copy pasta. The only variation is
some pages defined a "value" attribute. The "query" variable will
just be empty on pages that don't accept it. So let's consolidate
the template and remove the redundancy.
When on a filelog head, we are certain that there will be no descendant so the
target of the "descending" link will lead to an empty log result. Do not
display the link in this case.
These tests would run if hghave.has_serve() were enabled on Windows. Windows
has no issue allowing an unpriviledged process to open port 13, so it doesn't
abort. The other tests are related to how MSYS tries to be helpful and converts
Unix constructs to the Windows equivalent. There isn't any way to disable this
behavior, though it supposedly doesn't happen if the exe is linked against the
MSYS library.
In filerevision view (/file/<rev>/<fname>) we add some event listeners on
mouse clicks of <span> elements in the <pre class="sourcelines"> block.
Those listeners will capture a range of lines selected between two mouse
clicks and a box inviting to follow the history of selected lines will then
show up. Selected lines (i.e. the block of lines) get a CSS class which make
them highlighted. Selection can be cancelled (and restarted) by either
clicking on the cancel ("x") button in the invite box or clicking on any other
source line. Also clicking twice on the same line will abort the selection and
reset event listeners to restart the process.
As a first step, this action is only advertised by the "cursor: cell" CSS rule
on source lines elements as any other mechanisms would make the code
significantly more complicated. This might be improved later.
All JavaScript code lives in a new "linerangelog.js" file, sourced in
filerevision template (only in "paper" style for now).
This patch replaces hardcoded 127.0.0.1 with $LOCALIP in all tests.
Till now, the IPv6 series should make tests pass on common IPv6 systems
where the local device has the address "::1" and the hostname "localhost"
resolves to "::1".
All the hgweb templates include mercurial.js in their header. All
the hgweb templates have the same <script> boilerplate to run
process_dates(). This patch factors that function call into
mercurial.js as part of a DOMContentLoaded event listener.
This commit introduces support for advertising a server's support for
media types and compression formats in accordance with the spec defined
in internals.wireproto.
The bulk of the new code is a helper function in wireproto.py to
obtain a prioritized list of compression engines available to the
wire protocol. While not utilized yet, we implement support
for obtaining the list of compression engines advertised by the
client.
The upcoming HTTP protocol enhancements are a bit lower-level than
existing tests (most existing tests are command centric). So,
this commit establishes a new test file that will be appropriate
for holding tests around the functionality of the HTTP protocol
itself.
Rounding out this change, `hg debuginstall` now prints compression
engines available to the server.
Add white-space: nowrap to td.annotate to avoid wrapping div.annotate-info
into next line if there is revision number in the same cell, as it is hard to
mouse over div.annotate-info if it's wrapped into next line.
The link is embedded into a div with class="annotate-info" that only shows up
upon hover of the annotate column. To avoid duplicate hover-overs (this new
one and the one coming from link's title), drop "title" attribute from a
element and put it in the annotate-info element.
This patch includes addition of absolute_import and print_function to the
files where they are missing. The modern importing conventions are also followed.
It was mixing tabs and spaces, and not in a good way.
Indent style of other atom entries seems to be 1 space per level, so let's
apply it here as well.
It was mixing tabs and spaces, and not in a good way.
Indent style of other rss entries seems to be 4 spaces per level, so let's
apply it here as well.
* Distinguish the /annotate/<revision>/<file>#<linenumber> link when it would
lead to the current page (i.e. <revision> is the current revision) (style it
gray and undecorated). This indicates more clearly that this is a "dead-end"
in blame navigation.
* Display lines changed in current revision in green.
Changes, branches and tags are already in revlog order on /summary, /branches
and /tags, let's now make bookmarks be sorted by the same principle. It's more
helpful to show more "recent" bookmarks on top. This will affect /bookmarks
page in all styles, including atom, rss and raw, and also /summary page.
Bookmarks are sorted using a (revision number, bookmark name) tuple.
Before this patch, template files for "graph" web page use fixed width
size "480" for canvas element.
This causes pruned lanes and invisible vertexes, if there are 16 or
more vertical lanes at once. In such case, part of graph in right side
area over 480 is invisible, even though corresponded summary text
blocks are visible correctly.
This limitation isn't reasonable for workflow using many branches at
once (e.g. "one branch per issue" workflow).
There were changes below related to width of canvas:
- 6c855f5350cd (templates: widen the graph canvas (issue2683)),
released as a part of Mercurial 1.8.2
According to the description, this assumed that 15 parallel
branches was enough for ordinary workflow, and bumped width of
canvas up from 224 to 480.
- f5506d2a674c (hgweb: make graph data suitable for template usage),
released as a part of Mercurial 2.3
This introduced "canvaswidth" template keyword as a part of
refactoring around graph rendering.
But 'width="480"' of canvas element in template files wasn't
replaced by 'width="{canvaswidth}"' in it (or subsequent one).
This patch uses dynamic value "{canvaswidth}" instead of fixed width
size "480" for canvas element.
This is posted for "stable", because:
- this is re-fixing issue2683
- this is simple enough for stable
- using "{canvaswidth}" doesn't require any additional cost
Calculation of canvaswidth is already implied as a part of "graph"
web command.
In order to give us the freedom to change the changegroup3 format,
let's hide it behind an experimental config. Since it is required by
treemanifests, that will override the cg3 config.
I'm not entirely happy with using a trailing / on a "file" entry for
transferring a treemanifest. We've discussed putting some flags on
each file header[0], but I'm unconvinced that's actually any better:
if we were going to add another feature to the cg format we'd still be
doing a version bump anyway to cg4, so I'm inclined to not spend time
coming up with a more sophisticated format until we actually know what
the next feature we want to stuff in a changegroup will be.
Test changes outside test-treemanifest.t are only due to the new CG3
bundlecap showing up in the wire protocol.
Many thanks to adgar@google.com and martinvonz@google.com for helping
me with various odd corners of the changegroup and treemanifest API.
0: It's not hard refactoring, nor is it a lot of work. I'm just
disinclined to do speculative work when it's not clear what the
customer would actually be.
Any changes to the capabilities string was very hard to review. So we introduce two
tests. A small one that validates the format and a second one to validate the
content, where each capability is on its own line to make changes simpler to
review.
