Mon, 24 Sep 2018 22:45:32 -0400 keepalive: be more careful about self._rbuf when calling super impls
Augie Fackler <augie@google.com> [Mon, 24 Sep 2018 22:45:32 -0400] rev 39816
keepalive: be more careful about self._rbuf when calling super impls In Python 3, HTTPResponse implements read() in terms of readinto(), which was calling back into our readinto(), which duplicates self._rbuf if it's not empty. Before calling into super's read(), ensure self._rbuf is empty. Inheritance is bad, and undocumented self-use of your public API is one of many reasons. Differential Revision: https://phab.mercurial-scm.org/D4728
Mon, 17 Sep 2018 11:50:59 -0700 wireprotov2: teach changesetdata to fetch ancestors until depth
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 17 Sep 2018 11:50:59 -0700] rev 39815
wireprotov2: teach changesetdata to fetch ancestors until depth For shallow clone, it is useful to specify a starting node and tell the server to send up to N ancestors from that starting point. This enables the server to perform the DAG walk without the client having to discover the base/stop node(s) first. This commit implements support for said queries on the changesetdata command. Differential Revision: https://phab.mercurial-scm.org/D4621
Thu, 20 Sep 2018 12:57:23 -0700 wireprotov2: allow multiple fields to follow revision maps
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 20 Sep 2018 12:57:23 -0700] rev 39814
wireprotov2: allow multiple fields to follow revision maps The *data wire protocol commands emit a series of CBOR values. Because revision/delta data may be large, their data is emitted outside the map as a top-level bytestring value. Before this commit, we'd emit a single optional bytestring value after the revision descriptor map. This got the job done. But it was limiting in that we could only send a single field. And, it required the consumer to know that the presence of a key in the map implied the existence of a following bytestring value. This commit changes the encoding strategy so top-level bytestring values in the stream are explicitly denoted in a "fieldsfollowing" key. This key contains an array defining what fields that follow and the expected size of each field. By defining things this way, we can easily send N bytestring values without any ambiguity about their order. In addition, clients only need to know how to parse ``fieldsfollowing`` to know if extra values are present. Because this breaks backwards compatibility, we've bumped the version number of the wire protocol version 2 API endpoint. Differential Revision: https://phab.mercurial-scm.org/D4620
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 tip