Skip to content
Snippets Groups Projects
  1. Feb 27, 2018
    • Gregory Szorc's avatar
      wireproto: don't expose changegroupsubset capability if not available · e8995997
      Gregory Szorc authored
      We just marked the changegroupsubset command as only available to
      version 1 of the wire transports. There is a capability of the same
      name of the command that indicates if the command is supported.
      
      This commit teaches the capabilities code to conditionally emit that
      capability depending on whether the command is available for the
      current transport.
      
      Most test output is reordering of capabilities. But the limited tests
      for version 2 of the SSH protocol do show the capability disappearing.
      
      Differential Revision: https://phab.mercurial-scm.org/D2486
      e8995997
    • Gregory Szorc's avatar
      wireproto: don't expose legacy commands to version 2 of wire protocol · 6906547c
      Gregory Szorc authored
      Now that we have the ability to control which transports a wire
      protocol command is exposed on, let's put it to use.
      
      We flag the "branches," "changegroup," and "changegroupsubset"
      commands as only available on version 1. "branches" was used by the
      legacy discovery mechanism and was replaced by the "known" and
      "heads" commands. "changegroup" and "changegroupsubset" were
      replaced by "getbundle."
      
      "between" is also legacy. However, since it is used by the SSH
      handshake protocol, marking it as legacy is a bit more complicated
      and will be done in a later commit.
      
      Another nuanced issue with this change is that the server-advertised
      capabilities still list "changegroupsubset" despite the command not
      being available. This will be addressed in a subsequent commit.
      
      Differential Revision: https://phab.mercurial-scm.org/D2485
      6906547c
    • Gregory Szorc's avatar
      wireprotoserver: identify requests via version 2 of SSH protocol as such · af0d38f0
      Gregory Szorc authored
      The protocol handler needs to advertise itself as version 2 in order
      for a future feature to work.
      
      Differential Revision: https://phab.mercurial-scm.org/D2484
      af0d38f0
  2. Mar 02, 2018
    • Gregory Szorc's avatar
      wireproto: allow wire protocol commands to declare transport support · abc3b980
      Gregory Szorc authored
      Currently, wire protocol commands are exposed on all transports.
      Some wire protocol commands are only supported or sensical on some
      transports. In the future, new wire protocol commands may only be
      available on new transports and legacy wire protocol commands may
      not be available to newer transports.
      
      This commit introduces a mechanism to allow @wireprotocommand to
      declare transports for which they should not be available. The
      mechanism for determining if a wire protocol command is available
      for a given transport instance has been taught to take this knowledge
      into account.
      
      To help implement this feature, we add a dict to wireprototypes
      declaring all wire transports and their metadata. There's probably
      room to refactor the constants used to identify the wire protocols.
      But that can be in another commit.
      
      Differential Revision: https://phab.mercurial-scm.org/D2483
      abc3b980
    • Gregory Szorc's avatar
      sshpeer: don't read from stderr when that behavior is disabled · 1151c731
      Gregory Szorc authored
      We previously prevented the creation of doublepipe instances when
      we're not supposed to automatically read from stderr. However,
      there were other automatic calls to read from stderr that were
      undermining this effort.
      
      This commit prevents all automatic reads from stderr from occurring
      when they are supposed to be disabled.
      
      Because stderr is no longer being read, we need to call "readavailable"
      from tests so stderr is read from.
      
      Test output changes because stderr is now always (manually) read after
      stdout. And, since sshpeer no longer automatically tends to stderr,
      no "remote: " messages are printed. This should fix non-deterministic
      test output.
      
      FWIW, doublepipe automatically reads from stderr when reading from
      stdout, so I'm not sure some of these calls to self._readerr() are
      even needed.
      
      Differential Revision: https://phab.mercurial-scm.org/D2571
      1151c731
  3. Feb 15, 2018
  4. Feb 08, 2018
  5. Mar 02, 2018
  6. Feb 25, 2018
  7. Mar 02, 2018
  8. Mar 01, 2018
  9. Mar 02, 2018
Loading