When disabling the '#requires serve' check in test-hgwebdir.t and running it on
Windows, several 500 errors popped up when querying '?style=json', with the
following in the error log:
File "...\\mercurial\\templater.py", line 393, in runfilter
"keyword '%s'") % (filt.func_name, dt))
Abort: template filter 'json' is not compatible with keyword 'lastchange'
The swallowed exception at that point was:
File "...\\mercurial\\templatefilters.py", line 242, in json
raise TypeError('cannot encode type %s' % obj.__class__.__name__)
TypeError: cannot encode type long
This corresponds to 'lastchange' being populated by hgweb.common.get_stat(),
which uses os.stat().st_mtime. os.stat_float_times() is being disabled in util,
so the type for the times is 'long' on Windows, and 'int' on Linux.
When "patch" query parameter is present in requests to filelog view, line ids
in patches diff are no longer unique in the page since several patches are
shown on the same page. We now prefix line id by changeset shortnode when
several patches are displayed in the same page to have unique line ids
overall.
I ran into this python issue with an incomplete certificate chain on Windows
recently, and this is the clarification that came from that experimenting. The
comment I left on the bug tracker [1] with a reference to the CPython code [2]
indicates that the original problem I had is a different bug, but happened to
be mentioned under issue20916 on the Python bug tracker.
[1] https://bz.mercurial-scm.org/show_bug.cgi?id=5313#c7
[2] https://hg.python.org/cpython/file/v2.7.12/Modules/_ssl.c#l628
revlog.revision takes either node or rev, but taking a rev is more
efficient, because converting rev to node is just a seek and read.
That's cheaper than converting node to rev, which may require O(n) walk in
revlog index for the first times, and then triggering building the radix
tree index. Even with the radix tree built, rev -> node is still faster than
node -> rev because the radix tree requires more jumps in memory.
So r.revision(r.node(rev)) should be changed to r.revision(rev). This patch
adds a check-code rule to detect that.
Previously, when copying a file, copyfiles will compare src's st_dev with
dirname(dst)'s st_dev, to decide whether to enable hardlink or not.
That could have issues on Linux's overlayfs, where stating directories could
result in different st_dev from st_dev of stating files, even if both the
directories and the files exist in the overlay's upperdir.
This patch fixes it by checking dirname(src) instead. It's more consistent
because we are checking directories for both src and dest.
That fixes test-hardlinks.t running on common Docker setups.
As Yuya pointed out during a review a month ago, _admonitions and
_admonitiontitles are largely redundant. With the last commit, they
are exactly redundant. So, remove _admonitions and use
_admonitiontitles.keys() instead.
The "admonition" rst primitive is split into "specific" admonitions
("attention," "caution," etc) and the "generic" admonition
("admonition"). For more, see
http://docutils.sourceforge.net/docs/ref/rst/directives.html#admonitions
The _admonitions set and keys of the _admonitiontitles dict
overlap exactly except _admonitions has an "admonition" entry.
Nowhere in Mercurial is the "admonition" admonition directive used.
Even if it were, it doesn't have a title, so it wouldn't be rendered
correctly.
So, let's remove "admonition" from the set of recognized admonition
directives.
This is minor update along the way. We simplify the 'findglobaltags' function to
only return the tags. Since no existing data is reused, we know that all tags
returned are global and we can let the caller get that information if it cares
about it.
We move all arguments related to tagtype to the end, together. This will allow
us to make these arguments optional and reuse of this logic for callers that do
not care about the tag types.
The previous clause for filter out a diff hunk was too restrictive. We need to
consider the following cases (assuming linerange=(lb, ub) and the @s2,l2
hunkrange):
<-(s2)--------(s2+l2)->
<-(lb)---(ub)->
<-(lb)---(ub)->
<-(lb)---(ub)->
previously on the first and last situations were considered.
In test-hgweb-filelog.t, add a couple of lines at the beginning of file "b" so
that the line range we will follow does not start at the beginning of file.
This covers the change in aforementioned diff hunk filter clause.
Until now there were no label to highlight obsolete changesets in log output,
only evolution troubles (unstable, bumped, divergent) are supported. We add a
"changeset.obsolete" label on changeset entries produced by changeset_printer
so that obsolete changesets can be highlighted in log output. This is useful
because, unless using a graph log where obsolete changesets have a 'x' marker,
there's no way to identify obsolete changesets. And even in graph mode, when
working directory's parent is obsolete, we get a '@' marker and we do not see
it as obsolete.
Previously, fileset functions operating on status items performed
membership tests against a list of items. When there are thousands
of items having a specific status, that test can be extremely
slow. Changing the membership test to a set makes this operation
substantially faster.
On the mozilla-central repo:
$ hg files -r d14cac631ecc 'set:added()'
before: 28.120s
after: 0.860s
$ hg status --change d14cac631ecc --added
0.690s
a91c6275 introduces flushing ui buffers after a worker finished. If the ui was
not flushed before the worker was started, fork will copy the existing buffers
to the worker. This causes messages issued before the worker started to be
written to the terminal for each worker.
We are now flushing the ui before we start a worker and add an appropriate test
which will fail before this patch.
The function is only called once except for "hg debugconfig", where it is
called twice. So there is no need to cache it.
Caching it will cause issues with chgserver. Instead of dropping the cache
in chgserver, it seems cleaner to just avoid the cache.
When --pager=on is given, dispatch.py spawns a pager before setting up color.
If the pager failed to launch, ui.pageractive was left set to True, so color
configured itself based on 'color.pagermode'. A typical MSYS setting would be
'color.mode=auto, color.pagermode=ansi'. In the failure case, this would print
a warning, disable the pager, and then print the raw ANSI codes to the terminal.
Care needs to be taken, because it appears that leaving ui.pageractive=True was
the only thing that prevented an attempt at running the pager again from inside
the command. This results in a double warning message, so pager is simply
disabled on failure.
The ui config settings didn't need to be moved to fix this, but it seemed like
the right thing to do for consistency.
A future change will make color.setup() callable a second time when the pager is
spawned, in order to honor the 'color.pagermode' setting. The problem was that
when 'color.mode=auto' was resolved to 'win32' in the first pass, the default
ANSI effects were overwritten, making it impossible to honor 'pagermode=ansi'.
Also, the two separate maps didn't have the same keys. The symmetric difference
is 'dim' and 'italic' (from ANSI), and 'bold_background' (from win32). Thus,
the update left entries that didn't belong for the current mode. This bled
through `hg debugcolor`, where the unsupported ANSI keys were listed in 'win32'
mode.
As an added bonus, this now correctly enables color with MSYS `less` for a
command like this, where pager is forced on:
$ hg log --config color.pagermode=ansi --pager=yes --color=auto
Previously, the output was corrupted. The raw output, as seen through the ANSI
blind `more.com` was:
<-[-1;6mchangeset: 34840:3580d1197af9<-[-1m
...
which MSYS `less -FRX` rendered as:
1;6mchangeset: 34840:3580d1197af91m
...
(The two '<-' instances were actually an arrow character that TortoiseHg warned
couldn't be encoded, and notepad++ translated to a single '?'.)
Returning an empty map for 'ui._colormode == None' seems better that defaulting
to '_effects' (since some keys are mode dependent), and is better than None,
which blows up `hg debugcolor --color=never`.
Handling config and environ priorities has been messy. Partially because we
don't have config layers - you either get all configs (sys + user), or none.
Ideally, environ like $EDITOR, $PAGER should be able to override the system
configs "ui.editor", "pager.pager". This patch provides the ability to
convert them into config items, so they can be inserted into the middle
config layer between system rc and user rc.
The next patches will convert environ to raw config items, and insert the
config items between systemrcpath and userrcpath. This patch teaches
rccomponents to return the type information so the caller could distinguish
between "path" and raw config "items".
After this change, there are 3 rcpath functions:
- defaultrcpath
- systemrcpath
- userrcpath
This will allow us to insert another config layer in the middle.
As discussed at [1], the logic around "actual config"s seem to be
non-trivial enough that it's worth a new module.
This patch creates the module and move "scmutil.*rcpath" functions there as
the first step. More methods will be moved to the module in the future.
The module is different from config.py because the latter only cares about
data structure and parsing, and does not care about special case, or system
config paths, or environment variables.
[1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-March/095503.html
