Skip to content
Snippets Groups Projects
  1. Aug 03, 2018
    • Martin von Zweigbergk's avatar
      narrow: move status-filtering to core and to ctx · e411774a
      Martin von Zweigbergk authored
      One of my recent changes from repo.status(ctx1, ctx2) to
      ctx1.status(ctx2) broke some of our Google-internal tests. The problem
      turned out to be that the narrow extension was overriding
      repo.status() to make it filter out paths outside the narrowspec. When
      I changed to ctx1.status(ctx2), then that filtering obviously got
      lost. ctx.status() seems like a better method to do the filtering in,
      so this patch moves the filtering into that method, thereby also
      moving it out of the extension and into core.
      
      Differential Revision: https://phab.mercurial-scm.org/D4068
      e411774a
  2. Jul 10, 2018
  3. Aug 02, 2018
  4. Jun 11, 2018
  5. Aug 02, 2018
  6. Aug 01, 2018
  7. Aug 02, 2018
  8. Jul 29, 2018
    • Gregory Szorc's avatar
      exchange: move simple narrow changegroup generation from extension · d9908399
      Gregory Szorc authored
      The narrow extension completely replaced the function generating the
      changegroup part when a narrow changegroup was requested. Previous
      commits have taught the in-core changegroup code how to filter files
      based on a matcher. This commit teaches the in-core bundle2 part
      generation code to construct a matcher based on arguments. It
      will also emit a bundle2 part describing the narrow spec.
      
      I believe the changegroup part generation code in the narrow extension
      is now limited to ellipsis serving mode. i.e. core is now capable
      of narrow changegroup generation when ellipsis mode is disabled.
      
      Differential Revision: https://phab.mercurial-scm.org/D4014
      d9908399
    • Gregory Szorc's avatar
      exchange: make narrow ACL presence imply narrow=True · 98df52d5
      Gregory Szorc authored
      And refactor the logic for determining when to invoke our custom
      changegroup part function so it is only conditional on
      narrow being set. This makes it more obvious under which
      conditions we should invoke the custom implementation.
      
      Also use raw strings so **kwargs works on Python 3.
      
      Differential Revision: https://phab.mercurial-scm.org/D4013
      98df52d5
  9. Jul 28, 2018
  10. Jul 22, 2018
  11. Jul 21, 2018
  12. Jul 22, 2018
  13. Jul 05, 2018
  14. Aug 01, 2018
  15. Aug 02, 2018
  16. Jul 30, 2018
    • Augie Fackler's avatar
      linelog: add a Python implementation of the linelog datastructure · 422d6610
      Augie Fackler authored
      This datastructure was originally developed by Jun Wu at Facebook,
      inspired by SCCS weaves. It's useful as a cache for blame information,
      but also is the magic that makes `hg absorb` easy to implement. In
      service of importing the code to Mercurial, I wanted to actually
      /understand/ it, and once I did I decided to take a run at
      implementing it.
      
      The help/internals/linelog.txt document is the README from Jun Wu's
      implementaiton. It all applies to our linelog implementation.
      
      Differential Revision: https://phab.mercurial-scm.org/D3990
      422d6610
  17. Jul 28, 2018
    • Gregory Szorc's avatar
      changegroup: move file matcher from narrow extension · 1d01cf04
      Gregory Szorc authored
      Sparse changegroup generation requires the use of a matcher to
      filter which files are relevant.
      
      This commit moves the file matcher from the narrow extension to core
      and updates the narrow extension to use it.
      
      I'm not sure why the narrow extension was storing the matcher as
      a callable that resolved to a matcher. So I changed it to be a
      simple matcher instance.
      
      In addition, code from narrow to intersect the matcher with the local
      narrow spec is now performed automatically when the changegroup
      packer is created.
      
      If a matcher is not passed into getbundler() an alwaysmatcher() is
      assumed. This ensures that a matcher is always defined for all
      operations.
      
      Differential Revision: https://phab.mercurial-scm.org/D4011
      1d01cf04
  18. Jul 27, 2018
    • Kyle Lippincott's avatar
      resolve: add option to warn/abort on -m with unresolved conflict markers · 6c8e3c84
      Kyle Lippincott authored
      When a user is dropped out of Mercurial to a terminal to resolve files, we emit
      messages like:
      
          conflicts while merging file1! (edit, then use 'hg resolve --mark')
          conflicts while merging file2! (edit, then use 'hg resolve --mark')
      
      We don't mention a file name in the hint, so some users might do something like
      `$EDITOR file1; hg resolve --mark`, see that it says "(no more unresolved
      files)" and forget to deal with file2 before running the next command.
      
      Even if we did mention a file name in the hint, it's too easy to forget it
      (maybe the merge spans a couple days or something). This option lets us inform
      the user that they might have missed something.
      
      In the scenario above, the output would be something like:
      
          warning: the following files still have conflict markers:
            file2
          (no more unresolved files)
      
      Differential Revision: https://phab.mercurial-scm.org/D4035
      6c8e3c84
  19. Jul 03, 2018
  20. Jul 28, 2018
    • Gregory Szorc's avatar
      exchange: move disabling of rev-branch-cache bundle part out of narrow · 9b64b73d
      Gregory Szorc authored
      I'm attempting to refactor changegroup code in order to better
      support alternate storage backends. The narrow extension is
      performing a lot of monkeypatching to this code and it is making
      it difficult to reason about how everything works. I'm reasonably
      certain I would be unable to abstract storage without requiring
      extensive rework of narrow. I believe it is less effort to move
      narrow code into core so it can be accounted for when changegroup
      code is refactored. So I'll be doing that.
      
      The first part of this is integrating the disabling of the
      cache:rev-branch-cache bundle2 part into core. This doesn't seem
      like it is related to changegroup, but narrow's modifications to
      changegroup are invasive and also require taking its code for
      bundle generation and exchange into core in order for the changegroup
      code to work.
      
      Differential Revision: https://phab.mercurial-scm.org/D4007
      9b64b73d
  21. Jul 24, 2018
  22. Jul 25, 2018
  23. Aug 01, 2018
  24. Jul 31, 2018
    • Martijn Pieters's avatar
      manifest: persist the manifestfulltext cache · 0a57945a
      Martijn Pieters authored
      Reconstructing the manifest from the revlog takes time, so much so that there
      already is a LRU cache to avoid having to load a manifest multiple times.
      
      This patch persists that LRU cache in the .hg/cache directory, so we can re-use
      this cache across hg commands. Commit benchmark (run on Macos 10.13 on a
      2017-model Macbook Pro with Core i7 2.9GHz and flash drive), testing without
      and with patch run 5 times, baseline is r2a227782e754:
      
      * committing to an existing file, against the mozilla-central repository.
        Baseline real time average 1.9692, with patch 1.3786.
      
      A new debugcommand "hg debugmanifestfulltextcache" lets you inspect the cache,
      clear it, or add specific manifest nodeids to it. When calling
      repo.updatecaches(), the manifest(s) for the working copy parents are added to
      the cache.
      
      The hg perfmanifest command has an additional --clear-disk switch to clear this
      cache when testing manifest loading performance.
      
      Using this command to test performance on the firefox repository for revision
      f947d902ed91, whose manifest has a delta chain length of 60540, we see:
      
      $ hg perfmanifest f947d902ed91 --clear-disk
      ! wall 0.972253 comb 0.970000 user 0.850000 sys 0.120000 (best of 10)
      $ hg debugmanifestfulltextcache -a `hg log --debug -r f947d902ed91 | grep manifest | cut -d: -f3`
      Cache contains 1 manifest entries, in order of most to least recent:
      id: 0294517df4aad07c70701db43bc7ff24c3ce7dbc, size 25.6 MB
      Total cache data size 25.6 MB, on-disk 0 bytes
      $ hg perfmanifest f947d902ed91
      ! wall 0.036748 comb 0.040000 user 0.020000 sys 0.020000 (best of 100)
      
      Worst-case scenario: a manifest text loaded from a single delta; in the firefox
      repository manifest node 9a1246ff762e is the chain base for the manifest
      attached to revision f947d902ed91. Loading this from a full cache file is just
      as fast as without the cache; the extra node ids ensure a big full cache:
      
      $ for node in 9a1246ff762e 1a1922c14a3e 54a31d11a36a 0294517df4aa; do
      >   hgd debugmanifestfulltextcache -a $node > /dev/null
      > done
      $ hgd perfmanifest -m 9a1246ff762e
      ! wall 0.077513 comb 0.080000 user 0.030000 sys 0.050000 (best of 100)
      $ hgd perfmanifest -m 9a1246ff762e --clear-disk
      ! wall 0.078547 comb 0.080000 user 0.070000 sys 0.010000 (best of 100)
      0a57945a
    • Martijn Pieters's avatar
  25. Jul 20, 2018
Loading