FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 05 Jul 2016 07:25:51 +0900] rev 29495
perf: use locally defined revlog option list for Mercurial earlier than 3.7
Before this patch, referring commands.debugrevlogopts prevents perf.py
from being loaded by Mercurial earlier than 3.7 (or 5606f7d0d063),
because it isn't available in such Mercurial, even though
cmdutil.openrevlog(), a user of these options, has been available
since 1.9 (or a79fea6b3e77).
In addition to it, there are some code paths for Mercurial earlier
than 3.7. For example, setting "_prereadsize" attribute in perfindex()
and perfnodelookup() is effective only with hg earlier than 1.8 (or
61c9bc3da402).
But just "using locally defined revlog option list" might cause
unexpected behavior at runtime. If --dir option is specified to
cmdutil.openrevlog() of Mercurial earlier than 3.5 (or 49c583ca48c4),
it is silently ignored without any warning or so.
============ ============ ===== ===============
debugrevlogopts
hg version openrevlog() --dir of commands
============ ============ ===== ===============
3.7 or later o o o
3.5 or later o o x
1.9 or later o x x
earlier x x x
============ ============ ===== ===============
Therefore, this patch does:
- use locally defined option list, if commands.debugrevlogopts isn't
available (for Mercurial earlier than 3.7)
- wrap cmdutil.openrevlog(), if it is ambiguous whether
cmdutil.openrevlog() can recognize --dir option correctly
(for Mercurial earlier than 3.5)
This wrapper function aborts execution, if:
- --dir option is specified, and
- localrepository doesn't have "dirlog" attribute, which indicates
that localrepository has a function for '--dir'
BTW, extensions.wrapfunction() has been available since 1.1 (or
0ab5f21c390b), and this seems old enough for "historical
portability" of perf.py, which has been available since 1.1 (or
eb240755386d).
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 05 Jul 2016 07:25:51 +0900] rev 29494
perf: define util.safehasattr forcibly for Mercurial earlier than 1.9.3
Before this patch, using util.safehasattr() prevents perf.py from
being loaded by Mercurial earlier than 1.9.3 (or 94b200a11cf7),
because util.safehasattr() isn't available in such Mercurial, even
though there are some code paths for Mercurial earlier than 1.9.3.
For example, setting "_prereadsize" attribute in perfindex() and
perfnodelookup() is effective only with Mercurial earlier than 1.8 (or
61c9bc3da402).
This patch is a preparation for using util.safehasattr() safely in
subsequent patches.
This patch defines util.safehasattr() forcibly without examining
whether it is available or not, because:
- examining existence of "safehasattr" safely itself needs similar logic
- safehasattr() is small enough to define locally
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 05 Jul 2016 07:25:51 +0900] rev 29493
perf: add historical portability policy for future reference
Anton Shestakov <av6@dwimlabs.net> [Sat, 09 Jul 2016 14:01:55 +0800] rev 29492
tests: check ETag format in test-hgweb-commands
Anton Shestakov <av6@dwimlabs.net> [Sat, 09 Jul 2016 03:26:24 +0800] rev 29491
hgweb: emit a valid, weak ETag
Previously, ETag headers from hgweb weren't correctly formed, because rfc2616
(section 14, header definitions) requires double quotes around the content of
the header. str(web.mtime) didn't do that.
Additionally, strong ETags signify that the resource representations are
byte-for-byte identical. That is, they can be reconstructed from byte ranges if
client so wishes. Considering ETags for all hgweb pages is just mtime of
00changelog.i and doesn't consider of e.g. .hg/hgrc with description, contact
and other fields, it's clearly shouldn't be strong. The W/ prefix marks it as
weak, which still allows caching the whole served file/page, but doesn't allow
byte-range requests.
Maciej Fijalkowski <fijall@gmail.com> [Tue, 07 Jun 2016 15:35:58 +0200] rev 29490
policy: add cffi policy for PyPy
This adds cffi policy in the case where we don't want to use C modules,
but instead we're happy to rely on cffi (bundled with pypy)
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 04 Jul 2016 10:04:11 -0700] rev 29489
sslutil: handle default CA certificate loading on Windows
See the inline comment for what's going on here.
There is magic built into the "ssl" module that ships with modern
CPython that knows how to load the system CA certificates on
Windows. Since we're not shipping a CA bundle with Mercurial,
if we're running on legacy CPython there's nothing we can do
to load CAs on Windows, so it makes sense to print a warning.
I don't anticipate many people will see this warning because
the official (presumed popular) Mercurial distributions on
Windows bundle Python and should be distributing a modern Python
capable of loading system CA certs.
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 30 Jun 2016 19:54:12 -0700] rev 29488
sslutil: expand _defaultcacerts docstring to note calling assumptions
We should document this so future message additions don't seem out
of place.
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 04 Jul 2016 10:00:56 -0700] rev 29487
sslutil: document the Apple OpenSSL cert trick
This is sort of documented in _plainapplypython()'s docstring. But
it helps to be explicit in security code.
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 04 Jul 2016 09:58:45 -0700] rev 29486
sslutil: use certificates provided by certifi if available
The "certifi" Python package provides a distribution of the
Mozilla trusted CA certificates as a Python package. If it is
present, we assume the user intends it to be used and we use
it to provide the default CA certificates when certificates
are otherwise not configured.
It's worth noting that this behavior roughly matches the popular
"requests" package, which also attempts to use "certifi" if
present.