Skip to content
Snippets Groups Projects
  1. Jan 27, 2018
    • Matt Harbison's avatar
      lfs: add a fileset for detecting lfs files · eefb5d60
      Matt Harbison authored
      This currently has the same limitation as {lfs_files}, namely it doesn't report
      removed files.
      
      We may want a dedicated 'lfs()' revset for efficiency, but combining this with
      the 'contains()' revset should be equivalent for now.  Combining with
      'set:added()' or 'set:modified()' inside 'files()' should be equivalent to a
      hypothetical lfs_adds() and lfs_modifies().  I wonder if there's a way to tweak
      the filesets to evaluate lazily, to close the efficiency gap.
      
      It would also be interesting to come up with a template filter for '{files}'
      that looked at the pattern to 'files()', and filtered appropriately.  While
      passing a fileset as the pattern to `hg log` does filter '{files}', the set is
      evaluated against the working directory, so there's no way to list all non-lfs
      files above a certain size in all revisions, for example.
      eefb5d60
  2. Feb 08, 2018
    • Matt Harbison's avatar
      tests: stabilize ssh tests on Windows · c64b9adf
      Matt Harbison authored
      This seems like a somewhat common type of failure (double vs single quote), so
      I'm interested in ideas about how to avoid this.  I doubt that we should
      automatically fall back from single quote to double quote, like with '/' vs '\'.
      c64b9adf
  3. Feb 01, 2018
  4. Feb 02, 2018
    • Gregory Szorc's avatar
      wireprotoserver: document and improve the httplib workaround · 6010fe1d
      Gregory Szorc authored
      This workaround dates all the way back to a42d27bc809d in 2008.
      The code is esoteric enough to warrant an inline explanation.
      So I've added one.
      
      At the time the code was written, the only wire protocol command
      that accepted an HTTP request body was "unbundle." In the years
      since, we've grown the ability to accept command arguments via
      HTTP POST requests. So, the code has been changed to apply the
      httplib workaround to all HTTP POST requests.
      
      While staring at this code, I realized that the HTTP response
      body in case of error is always the same. And, it appears to
      mimic the behavior of a failed call to the "unbundle" command.
      Since we can hit this code path on theoretically any protocol
      request (since self.check_perm accepts custom auth checking
      functions which may raise), I'm having a hard time believing
      that clients react well to an "unbundle" response payload on
      any wire protocol command. I wouldn't be surprised if our test
      coverage for this feature only covers HTTP POST calls to
      "unbundle." In other words, the experimental support for sending
      arguments via HTTP POST request bodies may result in badness on
      the client. Something to investigate another time perhaps...
      
      Differential Revision: https://phab.mercurial-scm.org/D2064
      6010fe1d
  5. Feb 01, 2018
  6. Feb 02, 2018
    • Gregory Szorc's avatar
      largefiles: register wire protocol commands with modern APIs · f540b644
      Gregory Szorc authored
      The wireproto.wireprotocommand decorator is the preferred mechanism for
      registering wire protocol commands. In addition, wireproto.commands
      is no longer a 2-tuple and use of that 2-tuple API should be considered
      deprecated.
      
      This commit ports largefiles to use wireproto.wireprotocommand()
      and ports to the "commandentry" API.
      
      As part of this, the definition of the "lheads" wire protocol
      command is moved to the proper stanza.
      
      We stop short of actually using wireprotocommand as a decorator
      in order to minimize churn. We should ideally move wire protocol
      commands to the registrar mechanism. But that's for another
      changeset.
      
      Differential Revision: https://phab.mercurial-scm.org/D2018
      f540b644
  7. Jan 31, 2018
    • Gregory Szorc's avatar
      wireproto: function for testing if wire protocol command is available · 5a56bf41
      Gregory Szorc authored
      Currently, we perform simple membership testing for whether a wire
      command is available. In the future, not all wire protocol commands
      will be available on all transports. For example, a legacy transport
      may not support newer commands.
      
      In preparation of this, teach the protocol handlers to call into a
      function to determine if a wire protocol command is available. That
      function currently does membership testing like before, so behavior
      should be identical.
      
      In the case of the HTTP server, behavior is a bit wonkier. "cmd" is
      used by both the wire protocol and hgweb. We do want the protocol
      handler to handle requests for all commands that look like wire
      protocol commands, even if they aren't available. Otherwise, the
      fallback to hgweb would only confuse automated clients and make it
      easier for hgweb to accidentally implement a "cmd" that is identical
      to wire protocol commands (since they aren't centrally registered).
      
      Differential Revision: https://phab.mercurial-scm.org/D1999
      5a56bf41
    • Gregory Szorc's avatar
      wireproto: define and use types for wire protocol commands · ef683a0f
      Gregory Szorc authored
      Wire protocol commands have historically been declared as
      2-tuples in wireproto.commands. There are some additional features I'd
      like to implement that require going beyond 2-tuples. But because
      the 2-tuple API (both destructuring assignment and direct assignment
      into the dict) is used throughout the code base and in 3rd party
      extensions, we can't do a trivial type change.
      
      This commit creates a new "commandentry" type to represent declared
      wire protocol commands. It implements __getitem__ and __iter__ so
      it can quack like a 2-tuple. The @wireprotocommand decorator now
      creates "commandentry" instances.
      
      We also create a "commanddict" type to represent the dictionary of
      declared wire protocol commands. It inherits from "dict" but provides
      a custom __setitem__ to coerce passed 2-tuples to "commandentry"
      instances. wireproto.commands is now an instance of this type.
      
      Various callers in core rely on the new functionality. And tests
      pass. So I'm reasonably confident things will "just work" in 3rd
      party extensions as well.
      
      Differential Revision: https://phab.mercurial-scm.org/D1998
      ef683a0f
  8. Jan 30, 2018
  9. Jan 31, 2018
  10. Feb 06, 2018
    • Gregory Szorc's avatar
      sshpeer: implement peer for version 2 of wire protocol · 59e4a778
      Gregory Szorc authored
      Since the protocol is now negotiated before we construct a
      peer instance, we can return the negotiated protocol from the
      handshake function and instantiate an appropriate peer class
      for the protocol.
      
      Version 2 of the SSH protocol is currently identical to version
      1 post handshake. So our sshv2peer class just inherits from
      sshv1peer for the time being. This will obviously change
      over time.
      
      Differential Revision: https://phab.mercurial-scm.org/D2063
      59e4a778
    • Gregory Szorc's avatar
      sshpeer: rename sshpeer class to sshv1peer (API) · 625038cb
      Gregory Szorc authored
      With the introduction of version 2 of the SSH wire protocol,
      we will need a new peer class to speak that protocol because
      it will be too difficult to shoehorn a single class to speak
      two protocols. We rename sshpeer.sshpeer to sshpeer.sshv1peer
      to reflect the fact that there will be multiple versions of
      the peer depending on the negotiated protocol.
      
      .. api::
      
         sshpeer.sshpeer renamed to sshpeer.sshv1peer.
      
      Differential Revision: https://phab.mercurial-scm.org/D2062
      625038cb
    • Gregory Szorc's avatar
      sshpeer: initial definition and implementation of new SSH protocol · 48a3a928
      Gregory Szorc authored
      The existing SSH protocol has several design flaws. Future commits
      will elaborate on these flaws as new features are introduced
      to combat these flaws. For now, hopefully you can take me for my
      word that a ground up rewrite of the SSH protocol is needed.
      
      This commit lays the foundation for a new SSH protocol by defining
      a mechanism to upgrade the SSH transport channel away from the
      default (version 1) protocol to something modern (which we'll call
      "version 2" for now).
      
      This upgrade process is detailed in the internals documentation
      for the wire protocol. The gist of it is the client sends a
      request line preceding the "hello" command/line which basically
      says "I'm requesting an upgrade: here's what I support." If the
      server recognizes that line, it processes the upgrade request and
      the transport channel is switched to use the new version of the
      protocol. If not, it sends an empty response, which is how all
      Mercurial SSH servers from the beginning of time reacted to unknown
      commands. The upgrade request is effectively ignored and the client
      continues to use the existing version of the protocol as if nothing
      happened.
      
      The new version of the SSH protocol is completely identical to
      version 1 aside from the upgrade dance and the bytes that follow.
      The immediate bytes that follow the protocol switch are defined to
      be a length framed "capabilities: " line containing the remote's
      advertised capabilities. In reality, this looks very similar to
      what the "hello" response would look like. But it will evolve
      quickly.
      
      The methodology by which the protocol will evolve is important.
      
      I'm not going to introduce the new protocol all at once. That would
      likely lead to endless bike shedding and forward progress would
      stall. Instead, I intend to tricle out new features and diversions
      from the existing protocol in small, incremental changes.
      
      To support the gradual evolution of the protocol, the on-the-wire
      advertised protocol name contains an "exp" to denote "experimental"
      and a 4 digit field to capture the sub-version of the protocol.
      Whenever we make a BC change to the wire protocol, we can increment
      this version and lock out all older clients because it will appear
      as a completely different protocol version. This means we can incur
      as many breaking changes as we want. We don't have to commit to
      supporting any one feature or idea for a long period of time. We
      can even evolve the handshake mechanism, because that is defined
      as being an implementation detail of the negotiated protocol version!
      Hopefully this lowers the barrier to accepting changes to the
      protocol and for experimenting with "radical" ideas during its
      development.
      
      In core, sshpeer received most of the attention. We haven't even
      implemented the server bits for the new protocol in core yet.
      Instead, we add very primitive support to our test server, mainly
      just to exercise the added code paths in sshpeer.
      
      Differential Revision: https://phab.mercurial-scm.org/D2061
      
      # no-check-commit because of required foo_bar naming
      48a3a928
    • Gregory Szorc's avatar
      internals: refactor wire protocol documentation · 40d94ea5
      Gregory Szorc authored
      Upcoming work will introduce a new version of the HTTP and SSH
      transports. The differences will be significant enough to consider
      them new transports. So, we now attach a version number to each
      transport.
      
      In addition, having the handshake documented after the transport
      and in a single shared section made it harder to follow the flow
      of the connection. The handshake documentation is now moved to the
      protocol section it describes. We now have a generic section about
      the purpose of the handshake, which was rewritten significantly.
      
      Differential Revision: https://phab.mercurial-scm.org/D2060
      40d94ea5
  11. Feb 05, 2018
  12. Feb 06, 2018
  13. Feb 05, 2018
  14. Feb 03, 2018
  15. Feb 06, 2018
  16. Feb 07, 2018
  17. Feb 05, 2018
  18. Jan 21, 2018
  19. Feb 04, 2018
Loading