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
Mon, 17 Sep 2018 11:54:00 -0700 wireprotov2: advertise set of valid values for requestable fields
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 17 Sep 2018 11:54:00 -0700] rev 39813
wireprotov2: advertise set of valid values for requestable fields changesetdata, manifestdata, and filedata all allow the caller to specify what data fields to request. Data fields are extensible and may evolve over time. In order to prevent clients from making requests for fields that are not available, the client needs to know what fields are available. This commit teaches the server to declare a set of "valid values" for wire protocol command arguments. That set of values is exposed in the command's capabilities descriptor. The changesetdata, manifestdata, and filedata commands all declare their set of available "fields." Differential Revision: https://phab.mercurial-scm.org/D4619
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 tip