Skip to content
Snippets Groups Projects
  1. Sep 20, 2018
    • Gregory Szorc's avatar
      localrepo: support shared repo creation · 4ece3cdfd907
      Gregory Szorc authored
      Previously, hg.share() had its own logic for creating a new
      repository on the filesystem.
      
      With the recent introduction of the createopts dict for passing
      options to influence repository creation, it is now possible
      to consolidate the repo creation code for both the normal and
      shared use cases.
      
      This commit teaches the repo creation code in localrepo to
      recognize when we're creating a shared repo and to act
      appropriately.
      
      Meaningful behavior should be identical. However, there are a
      few subtle changes:
      
      * The .hg/requires file is written out in sorted order (rather
        than having share-related requirements appended at end).
      * The .hg directory is created with notindexed=True when a shared
        repo is being created.
      
      Differential Revision: https://phab.mercurial-scm.org/D4707
      4ece3cdfd907
  2. Sep 19, 2018
    • Gregory Szorc's avatar
      localrepo: validate directories before creating any · b504ff813c4f
      Gregory Szorc authored
      There is no meaningful change in behavior because wdir would
      already exist in the case where we raised RepoError. But I think
      the code is easier to read if we do all validation first then
      take actions with side-effects.
      
      Differential Revision: https://phab.mercurial-scm.org/D4706
      b504ff813c4f
    • Gregory Szorc's avatar
      localrepo: add missing join() · d3e761f9ac0a
      Gregory Szorc authored
      Differential Revision: https://phab.mercurial-scm.org/D4705
      d3e761f9ac0a
    • Gregory Szorc's avatar
      revlog: use proper version comparison during verify · e6d3d39cc1c7
      Gregory Szorc authored
      Verify appears to want to compare the changelog's revlog version
      number with the version number of filelogs and error if they are
      different. But what it was actually doing was comparing the full
      32-bit header integer, which contains 2 shorts: 1 for the revlog
      version number and 1 for feature flags.
      
      This commit tweaks the verification code so it only looks at the
      version number component of the header and emits a warning if they
      differ.
      
      The new code is more robust because it accounts for future revlog
      version numbers without them needing to be special cased.
      
      Differential Revision: https://phab.mercurial-scm.org/D4704
      e6d3d39cc1c7
    • Gregory Szorc's avatar
      filelog: stop proxying checksize() (API) · 0cb3e02e1d1b
      Gregory Szorc authored
      This was only used by verify code. And the check using it is now
      implemented as part of verifyintegrity(). The method is unused
      and is revlog-centric, which means it isn't appropriate for the file
      storage interface. So remove it.
      
      Differential Revision: https://phab.mercurial-scm.org/D4703
      0cb3e02e1d1b
    • Gregory Szorc's avatar
      filelog: remove version attribute (API) · 68282a7b29a7
      Gregory Szorc authored
      This was only used by verify code. The check it was used for is now
      implemented as part of the verifyintegrity() implementation. The
      attribute is now unused, is revlog-specific, and isn't appropriate
      to be exposing on the file storage interface. So drop it.
      
      Differential Revision: https://phab.mercurial-scm.org/D4702
      68282a7b29a7
    • Gregory Szorc's avatar
      verify: start to abstract file verification · 97986c9c69d3
      Gregory Szorc authored
      Currently, the file storage interface has a handful of attributes
      that are exclusively or near-exclusively used by repo verification
      code. In order to support verification on non-revlog/alternate
      storage backends, we'll need to abstract verification so it can
      be performed in a storage-agnostic way.
      
      This commit starts that process.
      
      We establish a new verifyintegrity() method on revlogs and expose
      it to the file storage interface. Most of verify.verifier.checklog()
      has been ported to this new method.
      
      We need a way to represent verification problems. So we invent an
      interface to represent a verification problem, invent a revlog type
      to implement that interface, and use it.
      
      The arguments to verifyintegrity() will almost certainly change in
      the future, once more functionality is ported from the verify code.
      And the "revlogv1" version check is very hacky. (The code in verify
      is actually buggy because it is comparing the full 32-bit header
      integer instead of just the revlog version short. I'll likely fix
      this in a subsequent commit.)
      
      Differential Revision: https://phab.mercurial-scm.org/D4701
      97986c9c69d3
  3. Sep 24, 2018
  4. Sep 26, 2018
  5. Sep 25, 2018
  6. Sep 26, 2018
  7. Sep 25, 2018
  8. Sep 26, 2018
  9. Sep 25, 2018
  10. Sep 23, 2018
  11. Sep 22, 2018
  12. Sep 24, 2018
  13. Sep 21, 2018
  14. Sep 25, 2018
  15. Sep 17, 2018
  16. Sep 20, 2018
    • Gregory Szorc's avatar
      wireprotov2: allow multiple fields to follow revision maps · d059cb669632
      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
      d059cb669632
  17. Sep 17, 2018
    • Gregory Szorc's avatar
      wireprotov2: advertise set of valid values for requestable fields · c30faea8d02d
      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
      c30faea8d02d
    • Gregory Szorc's avatar
      wireprotov2: expose rich arguments metadata · 8e7e822e85ec
      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
      8e7e822e85ec
    • Gregory Szorc's avatar
      wireprotov2: advertise recognized path filter prefixes · ae20f52437e9
      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
      ae20f52437e9
  18. Aug 31, 2018
    • Gregory Szorc's avatar
      wireprotov2: declare command arguments richly · 0b61d21f05cc
      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
      0b61d21f05cc
  19. Sep 26, 2018
    • Yuya Nishihara's avatar
      chgserver: do not send system() back to client if stdio redirected (issue5992) · 23a00bc90a3c
      Yuya Nishihara authored
      As the chg client doesn't know server-side stdio redirection, the server
      shouldn't upcall on "runsystem" request if the stdio streams are redirected.
      
      This patch teaches ui to remember the redirection flag, which is updated by
      the caller right now. Future patches (for default) will add ui methods to
      manage this flag internally.
      23a00bc90a3c
Loading