Gregory Szorc <gregory.szorc@gmail.com> [Mon, 22 Jan 2018 12:12:29 -0800] rev 35787
exchange: send bundle2 stream clones uncompressed
Stream clones don't compress well. And compression undermines
a point of stream clones which is to trade significant CPU
reductions by increasing size.
Building upon our introduction of metadata to communicate bundle
information back to callers of exchange.getbundlechunks(), we add
an attribute to the bundler that communicates whether the bundle is
best left uncompressed. We return this attribute as part of the bundle
metadata. And the wire protocol honors it when determining whether
to compress the wire protocol response.
The added test demonstrates that the raw result from the wire
protocol is not compressed. It also demonstrates that the server
will serve stream responses when the feature isn't enabled. We'll
address that in another commit.
The effect of this change is that server-side CPU usage for bundle2
stream clones is significantly reduced by removing zstd compression.
For the mozilla-unified repository:
before: 37.69 user 8.01 system
after: 27.38 user 7.34 system
Assuming things are CPU bound, that ~10s reduction would translate to
faster clones on the client. zstd can decompress at >1 GB/s. So the
overhead from decompression on the client is small in the grand scheme
of things. But if zlib compression were being used, the overhead would
be much greater.
Differential Revision: https://phab.mercurial-scm.org/D1926
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 22 Jan 2018 12:38:04 -0800] rev 35786
tests: update test to work with Git 2.16
It looks like Git 2.16 removed the "..." from some strings.
Glob over those characters in the test output.
Differential Revision: https://phab.mercurial-scm.org/D1935
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 20 Jan 2018 13:41:57 -0800] rev 35785
exchange: return bundle info from getbundlechunks() (API)
We generally want a mechanism to pass information about the
generated bundle back to callers (in addition to the byte stream).
Ideally we would return a bundler from this function and have the
caller code to an interface. But the bundling APIs are not great
and getbundlechunks() is the best API we have for obtaining bundle
contents in a unified manner.
We change getbundlechunks() to return a dict that we can use to
communicate metadata.
We populate that dict with the bundle version number to demonstrate
some value.
.. api::
exchange.getbundlechunks() now returns a 2-tuple instead of just
an iterator.
Differential Revision: https://phab.mercurial-scm.org/D1925
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 20 Jan 2018 15:26:31 -0800] rev 35784
exchange: make stream bundle part deterministic
repo.requirements is a set. We need to sort it so the part
content is deterministic.
Differential Revision: https://phab.mercurial-scm.org/D1924
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 20 Jan 2018 13:54:36 -0800] rev 35783
bundle2: specify what capabilities will be used for
We currently assume there is a symmetric relationship of bundle2
capabilities between client and server. However, this may not always be
the case.
We need a bundle2 capability to advertise bundle2 streaming clone support
on servers to differentiate it from the existing, legacy streaming clone
support.
However, servers may wish to disable streaming clone support. If bundle2
capabilities were the same between client and server, a client (which
may also be a server) that has disabled streaming clone support would
not be able to perform a streaming clone itself!
This commit introduces a "role" argument to bundle2.getrepocaps() that
explicitly defines the role being performed. This will allow us (and
extensions) to alter bundle2 capabilities depending on the operation
being performed.
Differential Revision: https://phab.mercurial-scm.org/D1923
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 20 Jan 2018 15:43:02 -0800] rev 35782
wireproto: don't compress errors from getbundle()
Errors should be small. There's no real need to compress them.
Truth be told, there's no good reason to not compress them either.
But leaving them uncompressed makes it easier to test failures
by looking at the raw HTTP response. This makes it easier for us
to write tests. It may make it easier for people writing their
own clients.
Differential Revision: https://phab.mercurial-scm.org/D1922
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 20 Jan 2018 16:08:07 -0800] rev 35781
tests: teach get-with-headers.py some new tricks
We add the ability to specify arbitrary HTTP request headers and
to save the HTTP response body to a file. These will be used in
upcoming commits.
Differential Revision: https://phab.mercurial-scm.org/D1921
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 20 Jan 2018 14:59:08 -0800] rev 35780
tests: use argparse in get-with-headers.py
I'm about to add another flag and I don't want to deal with this
organic, artisanal argument parser.
Differential Revision: https://phab.mercurial-scm.org/D1920
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 21 Jan 2018 17:11:31 -0800] rev 35779
convert: use a collections.deque
This function was doing a list.pop(0) on a list whose length
was the number of revisions to convert. Popping an early element
from long lists is not an efficient operation.
collections.deque supports efficient inserts and pops at both
ends. So we switch to that data structure.
When converting the mozilla-unified repository, which has 445,748
revisions, this change makes the "sorting..." step of
`hg convert --sourcesort` significantly faster:
before: ~59.2s
after: ~1.3s
Differential Revision: https://phab.mercurial-scm.org/D1934
Martin von Zweigbergk <martinvonz@google.com> [Sat, 20 Jan 2018 23:21:59 -0800] rev 35778
repair: invalidate volatile sets after stripping
Matt Harbison reported that some tests were broken on Windows after
1a09dad8b85a (evolution: report new unstable changesets,
2018-01-14). The failures were exactly as seen in this patch. The
failures actually seemed correct, which made me wonder why they didn't
fail the same way on Linux. It turned out to be a cache invalidation
problem.
The new orphan mentioned in the test case actually does get created
when we're re-applying the temporary bundle that's created while
stripping. However, without the invalidation, it appears that there
was already an orphan before applying the temporary bundle.
The warnings about unknown working parent appear because the
aformentioned changeset means that we're now accessing the dirstate
while it's invalid.
We may want to suppress these messages that happen in the intermediate
strip state, but they're technically correct (although confusing to
the user), so I think just fixing the cache invalidation is fine for
now.
I haven't figured out why the caches seemed to get correctly
invalidated on Windows.
Differential Revision: https://phab.mercurial-scm.org/D1933
Matt Harbison <matt_harbison@yahoo.com> [Sun, 21 Jan 2018 13:54:05 -0500] rev 35777
subrepo: handle 'C:' style paths on the command line (issue5770)
If you think 'C:' and 'C:\' are equivalent paths, see the inline comment before
proceeding.
The problem here was that several commands that take a URL argument (incoming,
outgoing, pull, and push) will use that value to set 'repo._subtoppath' on the
repository object after command specific manipulation of it, but before
converting it to an absolute path. When an operation is performed on a relative
subrepo, subrepo._abssource() will posixpath.join() this value with the relative
subrepo path. That adds a '/' after the drive letter, changing how it is
evaluated by abspath()/realpath() in vfsmod.vfs(..., realpath=True) as the
subrepo is instantiated.
I initially tried sanitizing the path in url.localpath(), because url.isabs()
only checks that it starts with a drive letter. By the sample behavior, this is
clearly not an absolute path. (Though the comment in isabs() is weasely- this
style path can't be joined either.) But not everything funnels through there,
and it required explicitly calling localpath() in hg.parseurl() and assigning to
url.path to fix. But then tests failed with urls like 'a#0'.
Next up was sanitizing the path in the url constructor. That caused doctest
failures, because there are drive letter tests, so those got expanded in system
specific ways. Yuya correctly pointed out that util.url is a parser, and
shouldn't be substituting the path too.
Rather than fixing every command call site, just convert it in the common
subrepo location. I don't see any sanitizing on the path config options, so I
fixed those too. Note that while the behavior is fixed here, there are still
places where 'comparing with C:' gets printed out, and that's not great for
debugging purposes. (Specifically I saw it in `hg incoming -B C:`, without
subrepos.) While clone will write out an absolute default path, I wonder what
would happen if a user edited that path to be 'C:'. (I don't think supporting
relative paths in .hgrc is a sane thing to do, but while we're poking holes in
things...)
Since this is such an oddball case, it still leaks through in places, and there
seems to be a lot of duplicate url parsing, maybe the url parsing should be
moved to dispatch, and provide the command with a url object? Then we could
convert this to an absolute path once, and not have to worry about it in the
rest of the code.
I also checked '--cwd C:' on the command line, and it was previously working
because os.chdir() will DTRT.
Finally, one other note from the url.localpath() experimenting. I don't see any
cases where 'self._hostport' can hold a drive letter. So I'm wondering if that
is wrong/old code.
Matt Harbison <matt_harbison@yahoo.com> [Mon, 22 Jan 2018 00:39:42 -0500] rev 35776
dummysmtpd: don't die on client connection errors
The connection refused error in test-patchbomb-tls.t[1] is sporadic, but one of
the more often seen errors on Windows. I added enough logging to a file and
dumped it out at the end to make the following observations:
- The listening socket is successfully created and bound to the port, and the
"listening at..." message is always logged.
- Generally, the following is the entire log output, with the "accepted ..."
message having been added after `sslutil.wrapserversocket`:
listening at localhost:$HGPORT
$LOCALIP ssl error
accepted connect
accepted connect
$LOCALIP from=quux to=foo, bar
$LOCALIP ssl error
- In the cases that fail, asyncore.loop() in the run() method is exiting, but
not with an exception.
- In the cases that fail, the following is logged right after "listening ...":
Traceback (most recent call last):
File "c:\\Python27\\lib\\asyncore.py", line 83, in read
obj.handle_read_event()
File "c:\\Python27\\lib\\asyncore.py", line 443, in handle_read_event
self.handle_accept()
File "../tests/dummysmtpd.py", line 80, in handle_accept
conn = sslutil.wrapserversocket(conn, ui, certfile=self._certfile)
File "..\\mercurial\\sslutil.py", line 570, in wrapserversocket
return sslcontext.wrap_socket(sock, server_side=True)
File "c:\\Python27\\lib\\ssl.py", line 363, in wrap_socket
_context=self)
File "c:\\Python27\\lib\\ssl.py", line 611, in __init__
self.do_handshake()
File "c:\\Python27\\lib\\ssl.py", line 840, in do_handshake
self._sslobj.do_handshake()
error: [Errno 10054] $ECONNRESET$
- If the base class handler is overridden completely, the the first "ssl
error" line is replaced by the stacktrace, but the other lines are
unchanged. The client behaves no differently, whether or not the server
stacktraced.
In general, `./run-tests.py --local -j9 -t9000 test-patchbomb-tls.t
--runs-per-test 20` would show the issue after a run or two. With this change,
`./run-tests.py --local -j9 -t9000 test-patchbomb-tls.t --loop` ran 800 times
without a hiccup. This makes me wonder if the other connection refused messages
that bubble up on occasion are caused by a similar issue. It seems a bit
drastic to kill the whole server on account of a single communication failure
with a client.
# no-check-commit because of handle_error()
[1] https://buildbot.mercurial-scm.org/builders/Win7%20x86_64%20hg%20tests/builds/421/steps/run-tests.py%20%28python%202.7.13%29/logs/stdio