Sat, 24 Feb 2018 01:20:20 +0530 py3: use util.forcebytestr instead of str to convert error messages
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 24 Feb 2018 01:20:20 +0530] rev 36388
py3: use util.forcebytestr instead of str to convert error messages Differential Revision: https://phab.mercurial-scm.org/D2411
Sat, 24 Feb 2018 01:19:26 +0530 py3: use pycompat.byteskwargs() to fix keyword arguments handling
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 24 Feb 2018 01:19:26 +0530] rev 36387
py3: use pycompat.byteskwargs() to fix keyword arguments handling I missed these when I fixed keyword arguments handling in the whole file. Differential Revision: https://phab.mercurial-scm.org/D2410
Fri, 23 Feb 2018 17:57:04 -0800 setup: only allow Python 3 from a source checkout (issue5804) stable
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 23 Feb 2018 17:57:04 -0800] rev 36386
setup: only allow Python 3 from a source checkout (issue5804) People are running `pip install Mercurial` with Python 3 and that is working because not everything performs a Python version compatibility check. Modern versions of pip do recognize the "python_requires" keyword (https://packaging.python.org/tutorials/distributing-packages/#python-requires) which we set if using setuptools. But this isn't set nor recognized everywhere. To prevent people from accidentally installing Mercurial with Python 3 until Python 3 is officially supported, have setup.py fail when run with Python 3. But don't fail if we're running from a source checkout, as we don't want to anger Mercurial developers hacking on Python 3 nor Mercurial's test automation running from source checkouts. People running setup.py from source checkouts could still fall through a Python 3 crack. But at least the `pip install Mercurial` attempt will get nipped in the bud.
Fri, 23 Feb 2018 20:50:10 -0500 tests: add HTTP POST and PUT support to the $LOGDATE$ substitution
Matt Harbison <matt_harbison@yahoo.com> [Fri, 23 Feb 2018 20:50:10 -0500] rev 36385
tests: add HTTP POST and PUT support to the $LOGDATE$ substitution The lfs serving code uses both POST and PUT requests (and there's existing support for POST).
Fri, 23 Feb 2018 18:47:26 +0530 py3: make regex bytes in hgweb/webcommands.py
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 23 Feb 2018 18:47:26 +0530] rev 36384
py3: make regex bytes in hgweb/webcommands.py # skip-blame because just b'' prefix
Fri, 23 Feb 2018 18:23:51 +0530 py3: replace types.NoneType with type(None)
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 23 Feb 2018 18:23:51 +0530] rev 36383
py3: replace types.NoneType with type(None) types.NoneType is not present in Python 3.
Fri, 23 Feb 2018 18:12:20 +0530 py3: add missing b'' in test-arbitraryfilectx.t
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 23 Feb 2018 18:12:20 +0530] rev 36382
py3: add missing b'' in test-arbitraryfilectx.t # skip-blame as just b'' prefix
Fri, 23 Feb 2018 18:04:33 +0530 py3: pass ctx.rev() instead of ctx in range()
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 23 Feb 2018 18:04:33 +0530] rev 36381
py3: pass ctx.rev() instead of ctx in range()
Fri, 23 Feb 2018 18:03:58 +0530 py3: add b'' prefixes in test-alias.t
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 23 Feb 2018 18:03:58 +0530] rev 36380
py3: add b'' prefixes in test-alias.t # skip-blame as it's just b'' prefixes
Fri, 23 Feb 2018 17:26:45 +0530 py3: add b'' prefixes in test-revset.t
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 23 Feb 2018 17:26:45 +0530] rev 36379
py3: add b'' prefixes in test-revset.t # skip-blame because it's just b''
Fri, 23 Feb 2018 17:25:51 +0530 py3: make sure we use bytes in generate-working-copy-states.py
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 23 Feb 2018 17:25:51 +0530] rev 36378
py3: make sure we use bytes in generate-working-copy-states.py
Fri, 23 Feb 2018 17:15:36 +0530 py3: fix keyword arguments handling in hgext/acl.py
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 23 Feb 2018 17:15:36 +0530] rev 36377
py3: fix keyword arguments handling in hgext/acl.py # skip-blame because we added r'' prefixes
Fri, 23 Feb 2018 17:14:25 +0530 py3: use pycompat.bytestr to convert str returned by getpass.getuser to bytes
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 23 Feb 2018 17:14:25 +0530] rev 36376
py3: use pycompat.bytestr to convert str returned by getpass.getuser to bytes
Fri, 23 Feb 2018 16:57:17 +0530 py3: add b'' prefixes in test-abort-checkin.t
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 23 Feb 2018 16:57:17 +0530] rev 36375
py3: add b'' prefixes in test-abort-checkin.t # skip-blame because we just added a b'' prefix.
Wed, 21 Feb 2018 23:43:23 +0530 py3: add b'' prefixes in test-dispatch.py
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 21 Feb 2018 23:43:23 +0530] rev 36374
py3: add b'' prefixes in test-dispatch.py # skip-blame because this is just adding b'' prefixes
Thu, 22 Feb 2018 20:04:42 -0500 cleanup: say goodbye to manifestv2 format
Augie Fackler <augie@google.com> [Thu, 22 Feb 2018 20:04:42 -0500] rev 36373
cleanup: say goodbye to manifestv2 format This experiment was a bust: we'd hoped for smaller repository sizes, but things got larger. Google ended up rolling out tree manifests in a format that's compatible with the original manifest format, and I believe Facebook is doing the same. This code was never implemented as native speedups, so I'm pretty comfortable saying nobody is using the experimental feature. Let's rip it out. I noticed this code still kicking around because I was investigating a repo corruption issue for timeless. .. bc:: Support for the experimental manifestv2 format has been removed, as it was never completed and failed to meet expectations. Differential Revision: https://phab.mercurial-scm.org/D2393
Wed, 21 Feb 2018 16:47:39 -0800 wireproto: document the wonky push protocol for SSH
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 21 Feb 2018 16:47:39 -0800] rev 36372
wireproto: document the wonky push protocol for SSH It took me several minutes to figure out how the "unbundle" protocol worked. It turns out that the SSH protocol handler sends an empty reply that is interpreted as "OK to send" and only then does the client send the bundle payload. On top of that, the response is different depending on whether the operation was successful or not. I nearly pulled out my hair deciphering this. Differential Revision: https://phab.mercurial-scm.org/D2385
Wed, 21 Feb 2018 14:21:05 -0800 wireprototypes: move baseprotocolhandler from wireprotoserver
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 21 Feb 2018 14:21:05 -0800] rev 36371
wireprototypes: move baseprotocolhandler from wireprotoserver This is needed to prevent a cycle in an upcoming commit. Differential Revision: https://phab.mercurial-scm.org/D2384
Wed, 21 Feb 2018 14:02:23 -0800 sshpeer: defer pipe buffering and stderr sidechannel binding
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 21 Feb 2018 14:02:23 -0800] rev 36370
sshpeer: defer pipe buffering and stderr sidechannel binding The doublepipe and bufferedinputpipe types facilitate polling multiple pipes without blocking and for automatically forwarding output from the SSH server's stderr pipe to the ui as "remote: " output. This all happens automatically and callers don't need to worry about reading from multiple pipes. An upcoming change to version 2 of the SSH wire protocol will eliminate the use of stderr and move side-channel output into the "main" pipe. The SSH wire protocol will use a pair of unidirectional pipes - just like the HTTP protocol. In this future world, the doublepipe primitive isn't necessary because the stderr pipe won't be used. To prepare for eventually not using doublepipe, we delay the construction of this primitive from immediately after connection establishment to inside construction of the peer instance. The handshake occurs between these two events. So we had to teach the handshake code to read from stderr so any stderr output from the server is still attended to early in the connection lifetime. Differential Revision: https://phab.mercurial-scm.org/D2383
Wed, 21 Feb 2018 13:08:55 -0800 sshpeer: make pipe polling code more explicit
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 21 Feb 2018 13:08:55 -0800] rev 36369
sshpeer: make pipe polling code more explicit "hasbuffer" is a property on our special bufferedinputpipe class. When reading this code, I thought it might have had something special to do properties on built-in types. But "hasbuffer" doesn't appear in the CPython code base for either 2.7 or 3.7, so the answer is no. Let's make the code more explicit about the fact that it deals with our special bufferedinputpipe type. Differential Revision: https://phab.mercurial-scm.org/D2382
Mon, 19 Feb 2018 13:20:17 -0800 tests: store protocol payload in files
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 19 Feb 2018 13:20:17 -0800] rev 36368
tests: store protocol payload in files Upcoming changes to version 2 of the SSH protocol will introduce binary components to the protocol. It will be easier to eliminate trailing newlines and use binary in the tests if the protocol payload is being generated by Python. So use inline Python to write payloads to files and pipe those files to server processes instead of shell strings/variables. Differential Revision: https://phab.mercurial-scm.org/D2381
Wed, 21 Feb 2018 08:35:48 -0800 sshpeer: return framed file object when needed
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 21 Feb 2018 08:35:48 -0800] rev 36367
sshpeer: return framed file object when needed Currently, wireproto.wirepeer has a default implementation of _submitbatch() and sshv1peer has a very similar implementation. The main difference is that sshv1peer is aware of the total amount of bytes it can read whereas the default implementation reads the stream until no more data is returned. The default implementation works for HTTP, since there is a known end to HTTP responses (either Content-Length or 0 sized chunk). This commit teaches sshv1peer to use our just-introduced "cappedreader" class for wrapping a file object to limit the number of bytes that can be read. We do this by introducing an argument to specify whether the response is framed. If set, we returned a cappedreader instance instead of the raw pipe. _call() always has framed responses. So we set this argument unconditionally and then .read() the entirety of the result. Strictly speaking, we don't need to use cappedreader in this case and can inline frame decoding/read logic. But I like when things are consistent. The overhead should be negligible. _callstream() and _callcompressable() are special: whether framing is used depends on the specific command. So, we define a set of commands that have framed response. It currently only contains "batch." As a result of this change, the one-off implementation of _submitbatch() in sshv1peer can be removed since it is now safe to .read() the response's file object until end of stream. cappedreader takes care of not overrunning the frame. Differential Revision: https://phab.mercurial-scm.org/D2380
Wed, 21 Feb 2018 08:33:50 -0800 sshpeer: move logic for sending a request into a new function
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 21 Feb 2018 08:33:50 -0800] rev 36366
sshpeer: move logic for sending a request into a new function The **args being used to pass arbitrary command arguments is limiting because it makes it harder to control behavior of the function. We factor most of _callstream() into a new function that doesn't use **args. Differential Revision: https://phab.mercurial-scm.org/D2379
Wed, 21 Feb 2018 16:51:09 -0500 help: fix wording describing SSH requirements stable
Josef 'Jeff' Sipek <jeffpc@josefsipek.net> [Wed, 21 Feb 2018 16:51:09 -0500] rev 36365
help: fix wording describing SSH requirements
Thu, 22 Feb 2018 15:18:44 +0800 graphlog: document what "_" and "*" mean stable
Anton Shestakov <av6@dwimlabs.net> [Thu, 22 Feb 2018 15:18:44 +0800] rev 36364
graphlog: document what "_" and "*" mean Documenting "*" should've been a part of 9b3f95d9783d, but I somehow didn't notice that the symbols are explained in the command's help text.
Mon, 19 Feb 2018 15:57:28 -0800 sshpeer: rename _recv and _send to _readframed and _writeframed
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 19 Feb 2018 15:57:28 -0800] rev 36363
sshpeer: rename _recv and _send to _readframed and _writeframed Because it is reading and writing a chunk of data with a well-defined size. "recv" and "send" make it sound like things are a direct proxy to the underlying pipe, which they aren't. Differential Revision: https://phab.mercurial-scm.org/D2378
Wed, 21 Feb 2018 13:41:20 -0800 util: add a file object proxy that can read at most N bytes
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 21 Feb 2018 13:41:20 -0800] rev 36362
util: add a file object proxy that can read at most N bytes Sometimes we have data of a known size within a stream. For performance reasons, we don't want to pre-read this data (we want to allow consumers to read on demand). For simplicitly reasons, we don't want callers to necessarily know their data is coming from within an outer stream and there is a limit to how much they should read. The class introduced by this commit provides a very simple proxy around an underlying file object that allows the consumer to .read() up to N bytes from the file object. Attempts to read past this many bytes results in a simulated EOF. Differential Revision: https://phab.mercurial-scm.org/D2377
Mon, 05 Feb 2018 15:03:51 +0100 patches: release the GIL while applying the patch
Boris Feld <boris.feld@octobus.net> [Mon, 05 Feb 2018 15:03:51 +0100] rev 36361
patches: release the GIL while applying the patch This will allow multiple threads to apply patches at the same time.
Wed, 21 Feb 2018 11:43:12 +0100 perfbranchmap: allow to select the filter to benchmark
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 11:43:12 +0100] rev 36360
perfbranchmap: allow to select the filter to benchmark Running the branchmap computation on all filter levels can be expensive. Narrowing the run to some specific filters can speed up benchmarking time when working only on a subset of filter levels.
Wed, 21 Feb 2018 12:13:16 +0100 perfbranchmap: display 'unfiltered' for unfiltered performance
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 12:13:16 +0100] rev 36359
perfbranchmap: display 'unfiltered' for unfiltered performance This is slightly clearer than "None" and will help with coming changes to select the filter level we want timing for.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip