Skip to content
Snippets Groups Projects
  1. Apr 04, 2018
  2. Mar 17, 2018
  3. Mar 19, 2018
  4. Mar 17, 2018
    • Yuya Nishihara's avatar
      templater: abstract away from joinfmt · ebf139cbd4a1
      Yuya Nishihara authored
      Future patches will add a wrapper for a list of template mappings, which
      will implement a custom join() something like {join(mappings % template)}.
      
      The original join() function is broken down as follows:
      
        if hasattr(joinset, 'joinfmt'):
            # hybrid.join() where values must be a list or a dict
            joinitems((joinfmt(x) for x in values), sep)
        elif isinstance(joinset, templateutil.wrapped):
            # mappable.join()
            show()
        else:
            # a plain list, a generator, or a byte string; joinfmt was identity()
            joinset = templateutil.unwrapvalue(context, joinset)
            joinitems(pycompat.maybebytestr(joinset), joiner)
      ebf139cbd4a1
  5. Mar 20, 2018
  6. Mar 17, 2018
  7. Mar 18, 2018
  8. Mar 17, 2018
  9. Apr 04, 2018
  10. Mar 31, 2018
    • Gregory Szorc's avatar
      peer: make ui an attribute · e826fe7a08c7
      Gregory Szorc authored
      With abc interfaces, instance attributes could not satisfy
      @abc.abstractproperty requirements because interface conformance
      was tested at type creation time. When we created the abc
      peer interfaces, we had to make "ui" a @property to satisfy
      abc.
      
      Now that peer interfaces are using zope.interface and there is no
      import time validation (but there are tests validating instances
      conform to the interface), we can go back to using regular object
      attributes.
      
      Differential Revision: https://phab.mercurial-scm.org/D3069
      e826fe7a08c7
    • Gregory Szorc's avatar
      repository: port peer interfaces to zope.interface · 39f7d4ee8bcd
      Gregory Szorc authored
      zope.interface is superior. Let's switch to it.
      
      Unlike abc, which defines interfaces through a base class,
      zope.interface uses different types for interfaces and for
      implementations. So, we had to invent some new types to hold the
      interfaces in order to separate the interface from its default
      implementation.
      
      The names here could probably be better. I've been wanting to
      overhaul the peer interface for a while. And wire protocol version
      2 will force that work. So anticipate a refactoring of these
      interfaces in later commits.
      
      With this commit, we no longer test abc interfaces in
      test-check-interfaces.py, so code for that has been removed.
      
      Differential Revision: https://phab.mercurial-scm.org/D3068
      
      # no-check-commit because of stream_out()
      39f7d4ee8bcd
  11. Mar 30, 2018
  12. Apr 02, 2018
  13. Mar 19, 2018
  14. Apr 03, 2018
  15. Apr 02, 2018
  16. Apr 03, 2018
  17. Mar 28, 2018
  18. Mar 23, 2018
  19. Mar 28, 2018
    • Gregory Szorc's avatar
      wireproto: separate commands tables for version 1 and 2 commands · 45b39c69fae0
      Gregory Szorc authored
      We can't easily reuse existing command handlers for version 2
      commands because the response types will be different. e.g. many
      commands return nodes encoded as hex. Our new wire protocol is
      binary safe, so we'll wish to encode nodes as binary.
      
      We /could/ teach each command handler to look at the protocol
      handler and change behavior based on the version in use. However,
      this would make logic a bit unwieldy over time and would make
      it harder to design a unified protocol handler interface. I think
      it's better to create a clean break between version 1 and version 2
      of commands on the server.
      
      What I imagine happening is we will have separate @wireprotocommand
      functions for each protocol generation. Those functions will parse the
      request, dispatch to a common function to process it, then generate
      the response in its own, transport-specific manner.
      
      This commit establishes a separate table for tracking version 1
      commands from version 2 commands. The HTTP server pieces have been
      updated to use this new table.
      
      Most commands are marked as both version 1 and version 2, so there is
      little practical impact to this change.
      
      A side-effect of this change is we now rely on transport registration
      in wireprototypes.TRANSPORTS and certain properties of the protocol
      interface. So a test had to be updated to conform.
      
      Differential Revision: https://phab.mercurial-scm.org/D2982
      45b39c69fae0
    • Gregory Szorc's avatar
      wireproto: mark SSHv2 as a version 1 transport · 27527d8cff5c
      Gregory Szorc authored
      The version component is used for filtering/routing wire protocol
      commands to their proper handler. The actual version 2 of the wire
      protocol commands will use a different encoding of responses. We
      already have tests using the version 2 SSH transport and version 2
      of the wire protocol commands won't be implemented atomically.
      
      This commit marks the SSHv2 transport as version 1 so it will
      still invoke the version 1 commands. Once the commands are all
      implemented in version 2, we can restore its proper behavior.
      
      Some tests had to be disabled as a result of this change.
      
      Differential Revision: https://phab.mercurial-scm.org/D2981
      27527d8cff5c
    • Gregory Szorc's avatar
      wireproto: stop aliasing wire protocol types (API) · d5d665f6615a
      Gregory Szorc authored
      We generally shy away from aliasing module symbols. I think I
      was keeping this around for API compatibility. We've already made
      tons of other API breaks in the wire protocol code this release.
      What's one more?
      
      .. api::
      
         ``wireproto`` module no longer re-exports various types used to
         define responses to wire protocol commands. Access these types
         from the ``wireprototypes`` module.
      
      Differential Revision: https://phab.mercurial-scm.org/D2979
      d5d665f6615a
  20. Mar 26, 2018
    • Gregory Szorc's avatar
      wireproto: use CBOR for command requests · 3d0e2cd86e05
      Gregory Szorc authored
      Now that we're using CBOR in the new wire protocol, let's convert
      command requests to it.
      
      Before I wrote this patch and was even thinking about CBOR, I was
      thinking about how commands should be issued and came to the
      conclusion that we didn't need separate frames to represent the
      command name from its arguments. I already had a partially
      completed patch prepared to merge the frames.
      
      But with CBOR, it makes the implementation a bit simpler because
      we don't need to roll our own serialization.
      
      The changes here are a bit invasive. I tried to split this into
      multiple commits to make it easier to review. But it was just too
      hard.
      
      * "command name" and "command argument" frames have been collapsed
        into a "command request" frame.
      * The flags for this new frame are totally different.
      * Frame processing has been overhauled to reflect the new order
        of things.
      * Test fallout was significant. A handful of tests were removed.
      
      Altogether, I think the new code is simpler. We don't have
      complicated state around receiving commands. We're either receiving
      command request frames or command data frames. We /could/
      potentially collapse command data frames into command request
      frames. Although I'd have to think a bit more about this before
      I do it.
      
      Differential Revision: https://phab.mercurial-scm.org/D2951
      3d0e2cd86e05
    • Gregory Szorc's avatar
      wireproto: define frame to represent progress updates · b0041036214e
      Gregory Szorc authored
      Today, a long-running operation on a server may run without any sign
      of progress on the client. This can lead to the conclusion that the
      server has hung or the connection has dropped. In fact, connections
      can and do time out due to inactivity. And a long-running server
      operation can result in the connection dropping prematurely because
      no data is being sent!
      
      While we're inventing the new wire protocol, let's provide a mechanism
      for communicating progress on potentially expensive server-side events.
      
      We introduce a new frame type that conveys "progress" updates. This
      frame type essentially holds the data required to formulate a
      ``ui.progress()`` call.
      
      We only define the frame right now. Implementing it will be a bit of
      work since there is no analog to progress frames in the existing
      wire protocol. We'll need to teach the ui object to write to the
      wire protocol, etc.
      
      The use of a CBOR map may seem wasteful, as this will encode key
      names in every frame. This *is* wasteful. However, maps are
      extensible. And the intent is to always use compression via
      streams. Compression will make the overhead negligible since repeated
      strings will be mostly eliminated over the wire.
      
      Differential Revision: https://phab.mercurial-scm.org/D2902
      b0041036214e
Loading