Hannes Oldenburg <hannes.christian.oldenburg@gmail.com> [Wed, 27 Jul 2016 08:38:54 +0000] rev 29633
cmdutil: warnings not issued in cat if subrepopath overlaps
Previously a subrepository "sub" would cause no warnings to
be issued for a file "subnot/a", if it's not present in the
corresponding changeset when calling:
hg cat subnot/a
Gábor Stefanik <gabor.stefanik@nng.com> [Mon, 25 Jul 2016 17:00:42 +0200] rev 29632
graft: use opts.get() consistently
Make life easier for extension writers.
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 25 Jul 2016 12:00:55 -0700] rev 29631
sslutil: work around SSLContext.get_ca_certs bug on Windows (
issue5313)
SSLContext.get_ca_certs() can raise
"ssl.SSLError: unknown error (_ssl.c:636)" on Windows. See
https://bugs.python.org/
issue20916 for more info.
We add a try..except that swallows the exception to work around
this bug. If we encounter the bug, we won't print a warning
message about attempting to load CA certificates. This is
unfortunate. But there appears to be little we can do :/
Matt Mackall <mpm@selenic.com> [Mon, 18 Jul 2016 16:25:35 -0500] rev 29630
extdiff: escape path for docstring (
issue5301)
The existing code (a) assumed path would be specified in
encoding.encoding and (b) assumed unicode() objects wouldn't cause
other parts of Mercurial to blow up. Both are dangerous assumptions.
Since we don't know the encoding of path and can't pass non-ASCII
through docstrings, just escape the path and drop the early _(). Will
have to suffice until we can teach docstrings to handle UTF-8b
escaping.
This has the side-effect that the line containing the path is now
variable by the time it reaches _() and thus can't be translated.
Kostia Balytskyi <ikostia@fb.com> [Thu, 21 Jul 2016 15:55:47 -0700] rev 29629
update: fix bug when update tries to modify folder symlink
In
1e4512eac59e0114bc60ecbcdc4157fc0fa0439d, I introduced a new bug:
when a symlink points to a folder in commit A and to another folder
in commit B, while updating from A to B, Mercurial will try to use
removedir on this symlink, which will fail. This is a very bad bug,
since it basically renders symlinks to folders unusable in repos.
Added test case fails without a fix and passes with it.
Anton Shestakov <av6@dwimlabs.net> [Mon, 25 Jul 2016 12:59:52 +0800] rev 29628
spartan: make annotate popup use theme colors
Anton Shestakov <av6@dwimlabs.net> [Mon, 25 Jul 2016 12:37:58 +0800] rev 29627
monoblue: make annotate popup use theme colors
Anton Shestakov <av6@dwimlabs.net> [Mon, 25 Jul 2016 12:33:18 +0800] rev 29626
gitweb: make annotate popup use theme colors
Anton Shestakov <av6@dwimlabs.net> [Mon, 25 Jul 2016 12:22:17 +0800] rev 29625
paper: make annotate popup use theme colors
Yuya Nishihara <yuya@tcha.org> [Fri, 22 Jul 2016 22:12:12 +0900] rev 29624
templatekw: fix join format of parents keyword (
issue5292)
Since the default joinfmt() can't process a dict of multiple keywords, we
need a dedicated joinfmt for showparents().
Unlike revset(), parents are formatted as '{rev}:{node|formatnode}' by default.
We copy the default formatting just like showextras() and showfilecopies() do.
Yuya Nishihara <yuya@tcha.org> [Fri, 22 Jul 2016 22:00:46 +0900] rev 29623
templatekw: fix join format of revset() function
It's been broken since
e4609ec959f8, which made makemap() return a dict of
multiple keywords. Because the default joinfmt() randomly picks one item
from a dict, we have to make revset() select d[name] explicitly.
Hannes Oldenburg <hannes.christian.oldenburg@gmail.com> [Fri, 22 Jul 2016 11:29:42 +0000] rev 29622
cmdutil: warnings not issued in remove if subrepopath overlaps
Previously a subrepository "sub" would cause no warnings to be issued
for a file "subnot/a" if it is not removed when calling:
hg remove -S "subnot/a"
Matt Mackall <mpm@selenic.com> [Wed, 20 Jul 2016 14:12:45 -0500] rev 29621
merge with i18n
Wagner Bruna <wbruna@softwareexpress.com.br> [Tue, 19 Jul 2016 19:01:11 -0300] rev 29620
i18n-pt_BR: synchronized with
519bb4f9d3a4
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 19 Jul 2016 21:09:58 -0700] rev 29619
sslutil: improve messaging around unsupported protocols (
issue5303)
There are various causes for the inability to negotiate common SSL/TLS
protocol between client and server. Previously, we had a single, not
very actionable warning message for all of them.
As people encountered TLS 1.0 servers in real life, it was quickly
obvious that the existing messaging was inadequate to help users
rectify the situation.
This patch makes the warning messages much more verbose in hopes of
making them more actionable while simultaneously encouraging users
and servers to adopt better security practices.
This messaging flirts with the anti-pattern of "never blame the
user" by signaling out poorly-configured servers. But if we're going to
disallow TLS 1.0 by default, I think we need to say *something* or
people are just going to blame Mercurial for not being able to connect.
The messaging tries to exonerate Mercurial from being the at fault
party by pointing out the server is the entity that doesn't support
proper security (when appropriate, of course).
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 19 Jul 2016 20:30:29 -0700] rev 29618
sslutil: capture string string representation of protocol
This will be used in a subsequent patch to improve messaging.
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 19 Jul 2016 20:16:51 -0700] rev 29617
sslutil: allow TLS 1.0 when --insecure is used
--insecure is our psuedo-supported footgun for disabling connection
security.
The flag already disables CA verification. I think allowing the use of
TLS 1.0 when specified is appropriate.
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 19 Jul 2016 19:57:34 -0700] rev 29616
hg: copy [hostsecurity] options to remote ui instances (
issue5305)
TIL that ui instances for remote/peer repos don't automagically inherit
config options from .hg/hgrc files.
This patch makes remote ui instances inherit options from the
[hostsecurity] section. We were already inheriting options
from [hostfingerprints] and [auth]. So adding [hostsecurity] to the
list seems appropriate.
Mads Kiilerich <madski@unity3d.com> [Mon, 18 Jul 2016 22:25:09 +0200] rev 29615
rbc: fix superfluous rebuilding from scratch - don't abuse self._rbcnamescount
The code used self._rbcnamescount as if it was the length of self._names ...
but actually it is just the number of good entries on disk. This caused the
cache to be populated inefficiently. In some cases very inefficiently.
Instead of checking the length before lookup, just try a lookup in self._names
- that is also in most cases faster.
Comments and debug messages are tweaked to help understanding the issue
and the fix.
Mads Kiilerich <madski@unity3d.com> [Mon, 18 Jul 2016 22:23:44 +0200] rev 29614
rbc: test case for incorrect and too aggressive invalidation of invalid caches
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 19 Jul 2016 10:15:35 -0700] rev 29613
util: better handle '-' in version string (
issue5302)
versiontuple() was previously only splitting on '+' and strings
like "3.9-rc" were causing it to misreport the version as
(3, None). By splitting on either '+' or '-' we can handle
our version strings with "-rc" in them.
Kevin Bullock <kbullock+mercurial@ringworld.org> [Tue, 19 Jul 2016 11:00:32 -0500] rev 29612
convert: update use of deprecated bzrlib property
The inventory property was deprecated in favor of root_inventory in bzr
2.5.0. Current version is 2.7.0.
I noticed this when testing locally on Python 2.6.9, which has warnings
turned on by default. The failure that occurs without this patch can be
seen on Python 2.7 by running with warnings enabled:
$ PYTHONWARNINGS=::DeprecationWarning make 'test-convert-bzr*'
Yuya Nishihara <yuya@tcha.org> [Tue, 19 Jul 2016 21:16:44 +0900] rev 29611
hghave: fix typo of sslutil.supportedprotocols
Simon Farnsworth <simonfar@fb.com> [Tue, 19 Jul 2016 03:29:53 -0700] rev 29610
rebase: turn rebase revs into set before filtering obsolete
When the inhibit extension from mutable-history is enabled, it attempts to
iterate over the rebaseset to prevent the nodes being rebased from being
marked obsolete. This happens at the same time as rebase's
_filterobsoleterevs function trying to iterate over the rebaseset to figure
out which ones are obsolete. The two of these iterating over the same
revset generatorset cause a 'generator already executing' exception. This is
probably a flaw in the revset implementation, since iterating over the same
set twice should be supported.
This regression was introduced in
5d16ebe7b14, since it changed
_filterobsoleterevs to be called before the rebaseset was turned into a
set(). For now let’s just make the rebaseset an actual set again before
calling that function. This was caught by the inhibit tests.
The relevant call stack from test-inhibit.t:
File "/tmp/hgtests.jgjrN5/install/lib/python/hgext/rebase.py", line 285, in _preparenewrebase
obsrevs = _filterobsoleterevs(self.repo, rebaseset)
File "/data/hgbuild/facebook-hg-rpms/mutable-history/hgext/inhibit.py", line 197, in _filterobsoleterevswrap
r = orig(repo, rebasesetrevs, *args, **kwargs)
File "/tmp/hgtests.jgjrN5/install/lib/python/hgext/rebase.py", line 1380, in _filterobsoleterevs
return set(r for r in revs if repo[r].obsolete())
File "/tmp/hgtests.jgjrN5/install/lib/python/hgext/rebase.py", line 1380, in <genexpr>
return set(r for r in revs if repo[r].obsolete())
File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 3079, in _iterordered
val2 = next(iter2)
File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 3417, in gen
yield nextrev()
File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 3424, in _consumegen
for item in self._gen:
File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 71, in iterate
cl = repo.changelog
File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/repoview.py", line 319, in changelog
revs = filterrevs(unfi, self.filtername)
File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/repoview.py", line 261, in filterrevs
repo.filteredrevcache[filtername] = func(repo.unfiltered())
File "/data/hgbuild/facebook-hg-rpms/mutable-history/hgext/directaccess.py", line 65, in _computehidden
hidden = repoview.filterrevs(repo, 'visible')
File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/repoview.py", line 261, in filterrevs
repo.filteredrevcache[filtername] = func(repo.unfiltered())
File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/repoview.py", line 175, in computehidden
hideable = hideablerevs(repo)
File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/repoview.py", line 33, in hideablerevs
return obsolete.getrevs(repo, 'obsolete')
File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/obsolete.py", line 1097, in getrevs
repo.obsstore.caches[name] = cachefuncs[name](repo)
File "/data/hgbuild/facebook-hg-rpms/mutable-history/hgext/inhibit.py", line 255, in _computeobsoleteset
if getrev(n) not in blacklist:
File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 3264, in __contains__
return x in self._r1 or x in self._r2
File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 3348, in __contains__
for l in self._consumegen():
File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 3424, in _consumegen
for item in self._gen:
ValueError: generator already executing
Jun Wu <quark@fb.com> [Mon, 18 Jul 2016 15:59:08 +0100] rev 29609
commandserver: update comment about setpgid
Now setpgid has 2 main purposes: better handling for terminal-generated
SIGTSTP, SIGINT, and process-exit-generated SIGHUP. Update the comment to
explain things more clearly.
Jun Wu <quark@fb.com> [Sun, 17 Jul 2016 22:55:47 +0100] rev 29608
chg: forward SIGINT, SIGHUP to process group
These signals are meant to send to a process group, instead of a single
process: SIGINT is usually emitted by the terminal and sent to the process
group. SIGHUP usually happens to a process group if termination of a process
causes that process group to become orphaned.
Before this patch, chg will only forward these signals to the single server
process. This patch changes it to the server process group.
This will allow us to properly kill processes started by the forked server
process, like a ssh process. The behavior difference can be observed by
setting SSH_ASKPASS to a dummy script doing "sleep 100" and then run
"chg push ssh://dest-need-password-auth". Before this patch, the first Ctrl+C
will kill the hg process while ssh-askpass and ssh will remain alive. This
patch will make sure they are killed properly.
Matt Mackall <mpm@selenic.com> [Mon, 18 Jul 2016 23:31:51 -0500] rev 29607
Added signature for changeset
519bb4f9d3a4
Matt Mackall <mpm@selenic.com> [Mon, 18 Jul 2016 23:31:50 -0500] rev 29606
Added tag 3.9-rc for changeset
519bb4f9d3a4
Matt Mackall <mpm@selenic.com> [Mon, 18 Jul 2016 23:28:14 -0500] rev 29605
merge default into stable for 3.9 code freeze
Mads Kiilerich <madski@unity3d.com> [Mon, 18 Jul 2016 22:22:38 +0200] rev 29604
rbc: fix invalid rbc-revs entries caused by missing cache growth
It was in some cases possible to end up writing to the cache file without
growing it first. The range assignment in _setcachedata would append instead of
writing at the requested position and thus write the new record in the wrong
place.
To fix this, we avoid looking up in too small caches, and when growing the
cache, do it right before writing the new record to it so we know it has been
done correctly.
Mads Kiilerich <madski@unity3d.com> [Mon, 18 Jul 2016 22:21:42 +0200] rev 29603
rbc: test case for cache file not growing correctly, causing bad new entries
Jun Wu <quark@fb.com> [Mon, 18 Jul 2016 18:55:06 +0100] rev 29602
chg: handle EOF reading data block
We recently discovered a case in production that chg uses 100% CPU and is
trying to read data forever:
recvfrom(4, "",
1814012019, 0, NULL, NULL) = 0
Using gdb, apparently readchannel() got wrong data. It was reading in an
infinite loop because rsize == 0 does not exit the loop, while the server
process had ended.
(gdb) bt
#0 ... in recv () at /lib64/libc.so.6
#1 ... in readchannel (...) at /usr/include/bits/socket2.h:45
#2 ... in readchannel (hgc=...) at hgclient.c:129
#3 ... in handleresponse (hgc=...) at hgclient.c:255
#4 ... in hgc_runcommand (hgc=..., args=<optimized>, argsize=<optimized>)
#5 ... in main (argc=...
486922636, argv=..., envp=...) at chg.c:661
(gdb) frame 2
(gdb) p *hgc
$1 = {sockfd = 4, pid = 381152, ctx = {ch = 108 'l',
data = 0x
7fb05164f010 "st):\nTraceback (most recent call last):\n"
"Traceback (most recent call last):\ne", maxdatasize =
1814065152,"
" datasize =
1814064225}, capflags = 16131}
This patch addresses the infinite loop issue by detecting continuously empty
responses and abort in that case.
Note that datasize can be translated to ['l', ' ', 'l', 'a']. Concatenate
datasize and data, it forms part of "Traceback (most recent call last):".
This may indicate a server-side channeledoutput issue. If it is a race
condition, we may want to use flock to protect the channels.
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 18 Jul 2016 11:27:27 -0700] rev 29601
sslutil: more robustly detect protocol support
The Python ssl module conditionally sets the TLS 1.1 and TLS 1.2
constants depending on whether HAVE_TLSv1_2 is defined. Yes, these
are both tied to the same constant (I would think there would be
separate constants for each version). Perhaps support for TLS 1.1
and 1.2 were added at the same time and the assumption is that
OpenSSL either has neither or both. I don't know.
As part of developing this patch, it was discovered that Apple's
/usr/bin/python2.7 does not support TLS 1.1 and 1.2 (only TLS 1.0)!
On OS X 10.11, Apple Python has the modern ssl module including
SSLContext, but it doesn't appear to negotiate TLS 1.1+ nor does
it expose the constants related to TLS 1.1+. Since this code is
doing more robust feature detection (and not assuming modern ssl
implies TLS 1.1+ support), we now get TLS 1.0 warnings when running
on Apple Python. Hence the test changes.
I'm not super thrilled about shipping a Mercurial that always
whines about TLS 1.0 on OS X. We may want a follow-up patch to
suppress this warning.
Maciej Fijalkowski <fijall@gmail.com> [Mon, 11 Jul 2016 11:05:08 +0200] rev 29600
osutil: add darwin-only version of os.listdir using cffi
Yuya Nishihara <yuya@tcha.org> [Sun, 05 Jun 2016 12:29:08 +0900] rev 29599
url: drop support for proxying HTTP (not HTTPS) over CONNECT tunneling
It's been broken since
cca59ef27e60, which made ui argument mandatory. I've
tried several combinations of HTTP/HTTPS proxying on old/new Python versions,
but I couldn't figure out how to reach this code path. Also, wrapping HTTP
connection by SSLSocket seems wrong. My understanding is that self.realhostport
is set by _generic_start_transaction() if HTTPS connection is tunneled.
This patch removes proxy tunneling from httpconnection.connect() assuming
that it was dead code from the beginning. Note that HTTPS over tunneling
should be handled by httpsconnection class.
Yuya Nishihara <yuya@tcha.org> [Sat, 21 May 2016 18:16:39 +0900] rev 29598
chgserver: rename private functions and variables of chgunixservicehandler
self.address has been reanmed to self._realaddress to clarify that it can
be different from the address argument.
Yuya Nishihara <yuya@tcha.org> [Sun, 22 May 2016 14:06:37 +0900] rev 29597
chgserver: refactor initialization of real/base addresses
Instead of overwriting self.address, calculate it from the address argument,
which is the base address.
Yuya Nishihara <yuya@tcha.org> [Sun, 22 May 2016 14:05:34 +0900] rev 29596
chgserver: reorder functions in chgunixservicehandler
This should make it slightly easier to follow the call path.
Yuya Nishihara <yuya@tcha.org> [Sat, 21 May 2016 18:15:20 +0900] rev 29595
chgserver: use ui.debug() to print server debug messages
commandserver.log() is noop at this time because no client connection is
established.
Yuya Nishihara <yuya@tcha.org> [Sun, 05 Jun 2016 12:18:20 +0900] rev 29594
ssl: remove special case of web.cacerts=! from remoteui()
It was introduced by
b76d8c641746, which is no longer necessary thanks to
recent refactoring of sslutil including
ef316c653b7f.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 17 Jul 2016 15:13:51 -0700] rev 29593
bundle2: store changeset count when creating file bundles
The bundle2 changegroup part has an advisory param saying how many
changesets are in the part. Before this patch, we were setting
this part when generating bundle2 parts via the wire protocol but
not when generating local bundle2 files.
A side effect of not setting the changeset count part is that progress
bars don't work when applying changesets. As the tests show, this
impacted clone bundles, shelve, backup bundles, `hg unbundle`, and
anything touching bundle2 files.
This patch adds a backdoor to allow us to pass state from
changegroup generation into the unbundler. We store the number
of changesets in the changegroup in this state and use it to
populate the aforementioned advisory part parameter when generating
the bundle2 bundle.
I concede that I'm not thrilled by how state is being passed in
changegroup.py (it feels a bit hacky). I would love to overhaul the
rather confusing set of functions in changegroup.py with something that
passes rich objects around instead of e.g. low-level generators.
However, given the code freeze for 3.9 is imminent, I'd rather not
undertake this endeavor right now. This feels like the easiest way
to get the parameter added to the changegroup part.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 17 Jul 2016 15:10:30 -0700] rev 29592
util: implement a deterministic __repr__ on sortdict
`hg debugbundle` is calling repr() on bundle2 part params, which are
now util.sortdict instances. Unfortunately, repr() doesn't appear
to be deterministic for util.sortdict. So, we implement one.
We include the type name because that's the common convention for
__repr__ implementations. Having the type name in `hg debugbundle`
is a bit ugly. But it's a debug command and I don't care enough to
fix it.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 17 Jul 2016 14:51:00 -0700] rev 29591
bundle2: use a sorted dict for holding parameters
An upcoming change that introduces a 2nd part parameter to a part
reveals that `hg debugbundle` isn't deterministic because parameters
are stored on n plain, unsorted dict.
While we could change that command to sort before output, I think
the more important underlying issue is that bundle2 reading is taking
an ordered data structure and converting it to an unordered one.
Plugging in util.sortdict() fixes that problem while preserving API
compatibility.
This patch also appears to shine light on the fact that we don't
have tests verifying parts with multiple parameters roundtrip
correctly. That would be a good thing to test (and fuzz)... someday.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 15 Jul 2016 13:41:34 -0700] rev 29590
wireproto: extract repo filtering to standalone function
As part of teaching Mozilla's replication extension to better handle
repositories with obsolescence data, I encountered a few scenarios
where I wanted built-in wire protocol commands from replication clients
to operate on unfiltered repositories so they could have access to
obsolete changesets.
While the undocumented "web.view" config option provides a mechanism
to choose what filter/view hgweb operates on, this doesn't apply
to wire protocol commands because wireproto.dispatch() is always
operating on the "served" repo.
This patch extracts the line for obtaining the repo that
wireproto commands operate on to its own function so extensions
can monkeypatch it to e.g. return an unfiltered repo.
I stopped short of exposing a config option because I view the use
case for changing this as a niche feature, best left to the domain
of extensions.
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Jul 2016 19:16:46 -0700] rev 29589
url: add distribution and version to user-agent request header (BC)
As a server operator, I've always wanted to know what Mercurial
version clients are running so I can track version adoption and
make informed decisions about which versions of Mercurial to
support in extensions. Unfortunately, there is no easy way to discern
this today: the best you can do is look for high-level feature usage
(e.g. bundle2) or sniff capabilities from bundle2 commands. And these
things aren't changed frequently enough to tell you anything that
interesting.
Nearly every piece of software talking HTTP sends its version in
the user agent. This includes web browsers, curl, and even Git.
This patch adds the distribution name and version to the user-agent
HTTP request header. We choose "Mercurial" for the distribution
name because that seems appropriate. The version string comes
from __version__.
The value is inside parenthesis for a few reasons:
* The version *may* contain spaces
* Alternate forms like "Mercurial/<version>" imply structure and
since the user agent should not be used by servers for protocol
or feature negotiation/detection, we don't want to even give the
illusion that the value should be parsed. A free form field is
the most hostile to parsing.
Flagging the patch as BC so it shows up in release notes. This
change should be backwards compatible. But I wouldn't be surprised if
a server somewhere is filtering on the exact old user agent string. So
I want to make noise about this change.
Yuya Nishihara <yuya@tcha.org> [Sat, 16 Jul 2016 14:48:58 +0900] rev 29588
commandserver: use SOMAXCONN as queue size of pending connections
The old value 5 was arbitrary chosen. Since there's no practical reason to
limit the backlog, this patch simply uses SOMAXCONN as a value large enough.
Yuya Nishihara <yuya@tcha.org> [Sat, 16 Jul 2016 14:46:31 +0900] rev 29587
commandserver: rename _serveworker() to _runworker()
"run" sounds more natural as the function does never listen for new connection.
Yuya Nishihara <yuya@tcha.org> [Sun, 22 May 2016 13:53:32 +0900] rev 29586
commandserver: separate initialization and cleanup of forked process
Separated _initworkerprocess() and _serverequest() can be reused when
implementing a prefork service.