Gregory Szorc <gregory.szorc@gmail.com> [Wed, 07 Feb 2018 20:24:22 -0800] rev 36069
wireprotoserver: rename _client to client (API)
This method is called in wireproto.py. It should be part of the public
API/interface.
.. api::
The ``_client()`` method of the wire protocol handler interface has
been renamed to ``client()``.
Differential Revision: https://phab.mercurial-scm.org/D2084
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 07 Feb 2018 20:20:11 -0800] rev 36068
wireprotoserver: remove redirect() and restore() (API)
These methods on the protocol handler interface are no longer used in
core.
.. api::
redirect() and restore() have been removed from the wire protocol
handler interface. Use mayberedirectstdio() instead.
Differential Revision: https://phab.mercurial-scm.org/D2083
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 07 Feb 2018 20:19:06 -0800] rev 36067
wireproto: use maybecapturestdio() for push responses (API)
The "pushres" and "pusherr" response types currently call
proto.restore() in the HTTP protocol. This completes the pairing
with proto.redirect() that occurs in the @wireprotocommand
functions. (But since the SSH protocol has a no-op redirect(),
it doesn't bother calling restore() because it would also be
a no-op.)
Having the disconnect between these paired calls is very confusing.
Knowing that you must use proto.redirect() if returning a "pushres"
or a "pusherr" is even wonkier.
We replace this confusing code with our new context manager for
[maybe] capturing output.
The "pushres" and "pusherr" types have gained an "output" argument
to their constructor and an attribute to hold captured data. The
HTTP protocol now retrieves output from these objects.
.. api::
``wireproto.pushres`` and ``wireproto.pusherr`` now explicitly
track stdio output.
Differential Revision: https://phab.mercurial-scm.org/D2082
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 07 Feb 2018 20:17:47 -0800] rev 36066
wireprotoserver: add context manager mechanism for redirecting stdio
Today, proto.redirect() sets up redirecting stdio and proto.restore()
undoes that. The API is a bit wonky because restore() is only
implemented on the HTTP protocol. Furthermore, not all calls to
redirect() are obviously paired with calls to restore(). For
example, the call to restore() for "unbundle" requests is handled
by the response handler for the HTTP protocol.
This commit introduces a new method on the protocol handler interface
to maybe capture stdio. It emits a file object or None depending on
whether stdio capture is used by the transport.
To prove it works, the "pushkey" wire protocol command has been
updated to use the new API.
I'm not convinced this is the best mechanism to capture stdio. I may
need to come up with something better once the new wire protocol
emerges into existence. But it is strictly better than before because
it removes variance in the wire protocol handler interface. It
therefore gets us closer to a unified interface between the SSH and
HTTP transports.
Differential Revision: https://phab.mercurial-scm.org/D2081
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 07 Feb 2018 20:17:05 -0800] rev 36065
wireprotoserver: split ssh protocol handler and server
We want to formalize the interface for protocol handlers. Today,
server functionality (which is domain specific) is interleaved
with protocol handling functionality (which conforms to a generic
interface) in the sshserver class.
This commit splits the ssh protocol handling code out of the
sshserver class.
Differential Revision: https://phab.mercurial-scm.org/D2080
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 07 Feb 2018 21:04:54 -0800] rev 36064
wireprotoserver: extract SSH response handling functions
The lookup/dispatch table was cute. But it isn't needed. Future
refactors will benefit from the handlers for individual response
types living outside the class.
As part of this, I snuck in a change that changes a type compare
from str to bytes. This has no effect on Python 2. But it might
make Python 3 a bit happier.
Differential Revision: https://phab.mercurial-scm.org/D2091
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 23 Dec 2017 15:13:37 +0530] rev 36063
remotenames: introduce new template keywords for remotenames
This patch introduces three new template keywords 'remotenames',
'remotebookmarks', 'remotebranches' to show remotenames, remotebookmarks and
remotebranches associated to a changeset.
This is a part of moving hgremotenames extension to core. The remotenames
template keyword was present in the extension and the rest of the two are not
present in the hgremotenames extension and are introduced in this patch.
hgremotenames: https://bitbucket.org/seanfarley/hgremotenames
Differential Revision: https://phab.mercurial-scm.org/D1759