Skip to content
Snippets Groups Projects
  1. Oct 17, 2018
  2. Oct 14, 2018
  3. Oct 05, 2018
    • Martin von Zweigbergk's avatar
      narrow: when widening, don't include manifests the client already has · 2c5835b4246b
      Martin von Zweigbergk authored
      When widening, we already don't include the changelog (since
      f1844a10ee19) and files that the client already has (since
      c73c7653dfb9). However, we still include all manifests needed for the
      new narrowspec. When using flat manifests, that means we resend all
      the manifests even though the client necessarily has all of them. For
      tree manifests, we unnecessarily resend the root manifests and any
      subdirectory manifests that the client already has.
      
      This patch makes it so we no longer resend manifests that the client
      already has. It does so by passing an extra matcher to the changegroup
      packer and it uses that for filtering out directories matching the old
      matcher's visitdir(). For consistency between directories and files,
      it also makes the filtering of files look at both old and new matcher
      rather than passing in a diff matcher as we did before.
      
      Differential Revision: https://phab.mercurial-scm.org/D4895
      2c5835b4246b
  4. Oct 17, 2018
  5. Oct 16, 2018
    • Kyle Lippincott's avatar
      revisions: when using prefixhexnode, ensure we prefix "0" · d916ed3ca951
      Kyle Lippincott authored
      Previously, if using `experimental.revisions.disambiguatewithin` (and it didn't
      include rev0), and '0' was the shortest identifier in that disambiguation set,
      we printed it as the shortest *without* a prefix. This was because we had logic
      to determine "if the prefix is a pure integer, but starts with 0, we don't need
      to prefix with 'x': 01 is not a synonym for revision #1", but didn't handle the
      case where prefix == 0 (which is a pure integer, and starts with 0... but it
      *is* "rev0").
      
      Differential Revision: https://phab.mercurial-scm.org/D5113
      d916ed3ca951
  6. Oct 03, 2018
  7. Sep 26, 2018
    • Pulkit Goyal's avatar
      streamclone: new server config and some API changes for narrow stream clones · af62936c2508
      Pulkit Goyal authored
      This patch introduces a new server config
      `experimental.server.stream-narrow-clones` which if set to True will advertise
      that the server supports narrow stream clones.
      
      This patch also pass on the includes and excludes from getbundle command to
      streamclone generation code.
      
      There is a test added to show that the includepats and excludepats are correctly
      passed.
      
      Upcoming patches will implement storage layer filtering for streamclones and
      then we can remove the temporary error and plug in the whole logic together to
      make narrow stream clones working.
      
      Differential Revision: https://phab.mercurial-scm.org/D5137
      af62936c2508
  8. Oct 10, 2018
    • Pulkit Goyal's avatar
      narrow: only send the narrowspecs back if ACL in play · cb516a854bc7
      Pulkit Goyal authored
      I am unable to think why we need to send narrowspecs back from the server. The
      current state adds a 'narrow:spec' part to each changegroup which is generated
      when narrow extension is enabled. So we are sending narrowspecs on pull also.
      
      There is a problem with sending the narrowspecs the way we are doing it right
      now. We add include and exclude as parameter of the 'narrow:spec' bundle2 part.
      The the len of include or exclude string increase 255 which is obvious while
      working on large repos, bundle2 generation code breaks. For more on that refer
      issue5952 on bugzilla.
      
      I was thinking why we need to send the narrowspecs back, and deleted the
      'narrow:spec' bundle2 part generation code and found that only narrow-acl test
      has some failure.
      
      With this patch, we will only send the 'narrow:spec' bundle2 part if ACL is
      enabled because the original narrowspecs in those cases can be a subset of
      narrowspecs user requested.
      
      There are phase related output change in couple of tests. The output change
      shows that we are now dealing in public phases completely. So maybe sending the
      narrow:spec bundle2 part was preventing phases being exchanged or phase bundle2
      data being applied.
      
      Differential Revision: https://phab.mercurial-scm.org/D4931
      cb516a854bc7
  9. Oct 17, 2018
  10. Oct 14, 2018
  11. Sep 14, 2018
    • Gregory Szorc's avatar
      exchange: support declaring pull depth · ac59de55c8b4
      Gregory Szorc authored
      Upcoming commits will teach exchangev2 how to perform a shallow
      clone. This commit teaches hg.clone(), exchange.pull(), and
      exchange.pulloperation to recognize a request for a shallow clone
      by having the caller specify a numeric depth of the maximum number of
      ancestor changesets to fetch.
      
      There are certainly other ways we could control shallow-ness. But this
      one is simple to implement and is also how the narrow extension
      controls things. So it seems to make sense to start here.
      
      Differential Revision: https://phab.mercurial-scm.org/D5136
      ac59de55c8b4
  12. Oct 17, 2018
    • Gregory Szorc's avatar
      exchangev2: support for calling rawstorefiledata to retrieve raw files · 00a4cd368e3f
      Gregory Szorc authored
      This is somewhat hacky. For that I apologize.
      
      At the 4.8 Sprint, we decided we wanted to land support in wireprotov2 for doing
      a partial clone with changelog and manifestlog bootstrapped from a "stream clone"
      like primitive.
      
      This commit implements the client-side bits necessary to facilitate that.
      
      If the new server-side command for obtaining raw files data is available, we
      call it to get the raw files for the changelog and manifestlog. Then we
      fall through to an incremental pull. But when fetching files data, instead
      of using the list of a changesets and manifests that we fetched via the
      "changesetdata" command, we do a linear scan of the repo and resolve the
      changeset and manifest nodes along with the manifest linkrevs.
      
      Differential Revision: https://phab.mercurial-scm.org/D5135
      00a4cd368e3f
  13. Oct 16, 2018
    • Gregory Szorc's avatar
      wireprotov2: implement command for retrieving raw store files · ed55a0077490
      Gregory Szorc authored
      Implementing shallow clone of the changelog is hard. We want the 4.8
      release to have a fast implementation of partial clone in wireprotov2. In
      order to achieve fast, we can't use deltas for transferring changelog and
      manifestlog data.
      
      Per discussions at the 4.8 sprint, this commit implements a somwwhat hacky
      and likely-to-be-changed-drastically-or-dropped command in wireprotov2 that
      facilitates access to raw store files, namely the changelog and manifestlog.
      Using this command, clients can perform a "stream clone" of sorts for just
      the changelog and manifestlog. This will allow clients to fetch the changelog
      and manifest revlogs, stream them to disk (which should be fast), then follow
      up filesdata requests for files revision data for a particular changeset.
      
      Differential Revision: https://phab.mercurial-scm.org/D5134
      ed55a0077490
    • Gregory Szorc's avatar
      wireprotov2: add response type that serializes to indefinite length bytestring · 2c55716f8a1c
      Gregory Szorc authored
      This will be needed in a future patch.
      
      Differential Revision: https://phab.mercurial-scm.org/D5133
      2c55716f8a1c
  14. Sep 26, 2018
    • Gregory Szorc's avatar
      exchangev2: recognize narrow patterns when pulling · 55836a34f41b
      Gregory Szorc authored
      pulloperation instances were recently taught to record file
      include and exclude patterns to facilitate narrow file transfer.
      Teaching the exchangev2 code to transfer a subset of files is
      as simple as constructing a narrow matcher from these patterns and
      filtering all seen file paths through it.
      
      Keep in mind that this change only influences file data: we're
      still fetching all changeset and manifest data. So, there's still
      a ton of "partial clone" to implement in exchangev2.
      
      On a personal note, I derive gratification that this feature requires
      very few lines of new code to implement.
      
      To test this, we implemented a minimal extension which allows us to specify
      --include/--exclude to clone. While the narrow extension provides these
      arguments, I explicitly wanted to test this functionality without the
      narrow extension enabled, as that extension monkeypatches various things
      and I want to isolate the behavior of core Mercurial.
      
      Differential Revision: https://phab.mercurial-scm.org/D5132
      55836a34f41b
  15. Oct 09, 2018
    • Gregory Szorc's avatar
      sqlitestore: file storage backend using SQLite · fed697fa1734
      Gregory Szorc authored
      This commit provides an extension which uses SQLite to store file
      data (as opposed to revlogs).
      
      As the inline documentation describes, there are still several
      aspects to the extension that are incomplete. But it's a start.
      The extension does support basic clone, checkout, and commit
      workflows, which makes it suitable for simple use cases.
      
      One notable missing feature is support for "bundlerepos." This is
      probably responsible for the most test failures when the extension
      is activated as part of the test suite.
      
      All revision data is stored in SQLite. Data is stored as zstd
      compressed chunks (default if zstd is available), zlib compressed
      chunks (default if zstd is not available), or raw chunks (if
      configured or if a compressed delta is not smaller than the raw
      delta). This makes things very similar to revlogs.
      
      Unlike revlogs, the extension doesn't yet enforce a limit on delta
      chain length. This is an obvious limitation and should be addressed.
      This is somewhat mitigated by the use of zstd, which is much faster
      than zlib to decompress.
      
      There is a dedicated table for storing deltas. Deltas are stored
      by the SHA-1 hash of their uncompressed content. The "fileindex" table
      has columns that reference the delta for each revision and the base
      delta that delta should be applied against. A recursive SQL query
      is used to resolve the delta chain along with the delta data.
      
      By storing deltas by hash, we are able to de-duplicate delta storage!
      With revlogs, the same deltas in different revlogs would result in
      duplicate storage of that delta. In this scheme, inserting the
      duplicate delta is a no-op and delta chains simply reference the
      existing delta.
      
      When initially implementing this extension, I did not have
      content-indexed deltas and deltas could be duplicated across files
      (just like revlogs). When I implemented content-indexed deltas, the
      size of the SQLite database for a full clone of mozilla-unified
      dropped:
      
      before: 2,554,261,504 bytes
      after:  2,488,754,176 bytes
      
      Surprisingly, this is still larger than the bytes size of revlog
      files:
      
      revlog files: 2,104,861,230 bytes
      du -b:        2,254,381,614
      
      I would have expected storage to be smaller since we're not limiting
      delta chain length and since we're using zstd instead of zlib. I
      suspect the SQLite indexes and per-column overhead account for the
      bulk of the differences. (Keep in mind that revlog uses a 64-byte
      packed struct for revision index data and deltas are stored without
      padding. Aside from the 12 unused bytes in the 32 byte node field,
      revlogs are pretty efficient.) Another source of overhead is file
      name storage. With revlogs, file names are stored in the filesystem.
      But with SQLite, we need to store file names in the database. This is
      roughly equivalent to the size of the fncache file, which for the
      mozilla-unified repository is ~34MB.
      
      Since the SQLite database isn't append-only and since delta chains
      can reference any delta, this opens some interesting possibilities.
      For example, we could store deltas in reverse, such that fulltexts
      are stored for newer revisions and deltas are applied to reconstruct
      older revisions. This is likely a more optimal storage strategy for
      version control, as new data tends to be more frequently accessed
      than old data. We would obviously need wire protocol support for
      transferring revision data from newest to oldest. And we would
      probably need some kind of mechanism for "re-encoding" stores. But
      it should be doable.
      
      This extension is very much experimental quality. There are a handful
      of features that don't work. It probably isn't suitable for day-to-day
      use. But it could be used in limited cases (e.g. read-only checkouts
      like in CI). And it is also a good proving ground for alternate
      storage backends. As we continue to define interfaces for all things
      storage, it will be useful to have a viable alternate storage backend
      to see how things shake out in practice.
      
      test-storage.py passes on Python 2 and introduces no new test failures on
      Python 3. Having the storage-level unit tests has proved to be insanely
      useful when developing this extension. Those tests caught numerous bugs
      during development and I'm convinced this style of testing is the way
      forward for ensuring alternate storage backends work as intended. Of
      course, test coverage isn't close to what it needs to be. But it is
      a start. And what coverage we have gives me confidence that basic store
      functionality is implemented properly.
      
      Differential Revision: https://phab.mercurial-scm.org/D4928
      fed697fa1734
  16. Oct 16, 2018
  17. Sep 21, 2018
    • Matt Harbison's avatar
      lfs: autoload the extension when cloning from repo with lfs enabled · 6637b079ae45
      Matt Harbison authored
      This is based on a patch by Gregory Szorc.  I made small adjustments to
      clean up the messaging when the server has the extension enabled, but the
      client has it disabled (to prevent autoloading).  Additionally, I added
      a second server capability to distinguish between the server having the
      extension enabled, and the server having LFS commits.  This helps prevent
      unnecessary requirement propagation- the client shouldn't add a requirement
      that the server doesn't have, just because the server had the extension
      loaded.  The TODO I had about advertising a capability when the server can
      natively serve up blobs isn't relevant anymore (we've had 2 releases that
      support this), so I dropped it.
      
      Currently, we lazily add the "lfs" requirement to a repo when we first
      encounter LFS data. Due to a pretxnchangegroup hook that looks for LFS
      data, this can happen at the end of clone.
      
      Now that we have more control over how repositories are created, we can
      do better.
      
      This commit adds a repo creation option to add the "lfs" requirement.
      hg.clone() sets this creation option if the remote peer is advertising
      lfs usage (as opposed to just support needed to push).
      
      So, what this change effectively does is have cloned repos
      automatically inherit the "lfs" requirement.
      
      Differential Revision: https://phab.mercurial-scm.org/D5130
      6637b079ae45
  18. Oct 16, 2018
  19. Aug 31, 2018
  20. Oct 11, 2018
  21. Oct 16, 2018
  22. Oct 14, 2018
Loading