Skip to content
Snippets Groups Projects
  1. Sep 25, 2018
  2. Sep 26, 2018
  3. Sep 25, 2018
  4. Sep 23, 2018
  5. Sep 22, 2018
  6. Sep 24, 2018
  7. Sep 21, 2018
  8. Sep 25, 2018
  9. Sep 17, 2018
  10. Sep 20, 2018
    • Gregory Szorc's avatar
      wireprotov2: allow multiple fields to follow revision maps · d059cb66
      Gregory Szorc authored
      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
      d059cb66
  11. Sep 17, 2018
    • Gregory Szorc's avatar
      wireprotov2: advertise set of valid values for requestable fields · c30faea8
      Gregory Szorc authored
      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
      c30faea8
    • Gregory Szorc's avatar
      wireprotov2: expose rich arguments metadata · 8e7e822e
      Gregory Szorc authored
      Now that we internally store rich metadata about arguments, it makes
      sense to make that metadata available to the client. This will allow
      clients to validate outgoing command requests before they are sent
      over the wire.
      
      Strictly speaking, we should bump the wire protocol version for this
      change since it is backwards incompatible. But no client-side code
      touches the arguments map and I don't want to incur the work.
      
      Differential Revision: https://phab.mercurial-scm.org/D4618
      8e7e822e
    • Gregory Szorc's avatar
      wireprotov2: advertise recognized path filter prefixes · ae20f524
      Gregory Szorc authored
      While the wire protocol doesn't yet support it, we'll eventually
      have commands that accept narrow patterns to specify the set of
      files relevant to a command.
      
      For security and performance reasons, only specific filter types
      are allowed.
      
      This commit teaches the server to advertise the set of allowed
      filter types. By doing so, clients can e.g. validate user-specified
      patterns against the server's abilities without having to send
      a command to retrieve data.
      
      Having the data in the capabilities data structure will also serve
      as a check against unwanted BC.
      
      Differential Revision: https://phab.mercurial-scm.org/D4616
      ae20f524
  12. Aug 31, 2018
    • Gregory Szorc's avatar
      wireprotov2: declare command arguments richly · 0b61d21f
      Gregory Szorc authored
      Previously, we declared command arguments with an example of
      their value. After this commit, we declare command arguments
      as a dict of metadata. This allows us to define the value
      type, whether the argument is required, and provide default
      values. This in turn allows us to have nice things, such as
      less boilerplate code in individual commands for validating
      input and assigning default values. It should also make command
      behavior more consistent as a result.
      
      Test output changed slightly because I realized that the "fields"
      argument wasn't being consistently defined as a set. Oops!
      
      Other test output changed because of slight differences in code
      performing type validation.
      
      Differential Revision: https://phab.mercurial-scm.org/D4615
      0b61d21f
  13. Sep 25, 2018
  14. Sep 15, 2018
  15. Sep 23, 2018
    • Yuya Nishihara's avatar
      hgweb: use scmutil.binnode() to translate None to wdir hash (issue5988) · 4f44f747
      Yuya Nishihara authored
      I left some of ctx.node() calls unchanged as they seemed unlikely to be
      workingctx, or passed to diff functions where None is the default value.
      
      Note that a None revision can also cause a similar problem, but I'm not sure
      if we can simply bulk-replace ctx.rev() with scmutil.intrev(ctx) as there's
      large hole between tip revision and wdir revision. If such pair were passed
      in to xrange() for example, we would waste CPU time.
      4f44f747
Loading