Skip to content
Snippets Groups Projects
  1. Sep 17, 2019
  2. Sep 13, 2019
    • Martin von Zweigbergk's avatar
      narrow: add option for automatically removing unused includes · 40f78072fda9
      Martin von Zweigbergk authored
      It's been a somewhat common request among our users to have Mercurial
      automatically pick includes to remove. This patch adds an option for
      that: `hg tracked --auto-remove-includes`. I'm not sure if this is the
      right name and semantics for it. Perhaps the feature should also add
      excludes of large subdirectories even if other files in the include
      are needed? Narrow clones are experimental, so we can change the name
      and/or semantics later if necessary.
      
      Differential Revision: https://phab.mercurial-scm.org/D6848
      40f78072fda9
    • Martin von Zweigbergk's avatar
      narrow: don't hexify paths and double-hexify known nodes on wire (BC) · c2676b5a9f59
      Martin von Zweigbergk authored
      It isn't obvious, but wireprototypes.encodelist() is meant only for
      binary nodeids. So when we used it for encoding hex nodeids and paths,
      the encoded result was surprising and hard to read.
      
      This patch changes the encoding to make the list of paths a
      comma-separated list and the list of common nodes to be a
      encodelist()-encoded list of binary nodeids (so the result is just
      singly-hexified nodeids).
      
      This is clearly a breaking change, but the feature is experimental and
      we're not aware of anyone running a server using this command yet.
      
      Differential Revision: https://phab.mercurial-scm.org/D6851
      c2676b5a9f59
  3. Sep 11, 2019
    • Boris Feld's avatar
      remotefilelog: replace repack lock to solve race condition · 5fadf6103790
      Boris Feld authored
      2c74337e6483 reduced the probability of race-conditions when starting
      background repack and prefetch and we saw the difference in our CI instance
      with all failures disappearing except one where one call to waitonrepack seems
      to returns too early.
      
      I'm not sure what exactly goes wrong but I realized that while the prefetch
      operation uses a standard Mercurial lock, the repack operation is using a
      custom lock based on `fcntl.flock` on available platforms. As `extutil.flock`
      fallback on traditional Mercurial locks on other platforms and the tests are
      stable on my laptop, our CI environment and GCC112, I'm sending this patch to
      standardize the behavior across environments.
      
      Differential Revision: https://phab.mercurial-scm.org/D6844
      5fadf6103790
  4. Sep 17, 2019
  5. Sep 15, 2019
  6. Sep 14, 2019
    • Matt Harbison's avatar
      tests: stabilize test-fix.t on Windows · a2dffe68b4ea
      Matt Harbison authored
      `pwd` prints /tmp/... style paths, not C:\... needed for $TESTTMP to be
      substituted.
      
      In the final test, for whatever reason, Windows was missing EOL in the files and
      printing:
      
          [wdir] changedlines: printf: warning: ignoring excess arguments, starting
             with 'printf'
      
      even though it was trying to run:
      
          printf "Line ranges:\n"; printf "2 through 2\n";
      
      I tried wrapping both :command and :linerange in `sh -c "..."`, and while that
      fixed the missing EOL, it missed the "2 through 2" output.
      
      Differential Revision: https://phab.mercurial-scm.org/D6852
      a2dffe68b4ea
  7. Sep 16, 2019
    • Gregory Szorc's avatar
      zstandard: vendor python-zstandard 0.12 · 69de49c4e39c
      Gregory Szorc authored
      The upstream source distribution from PyPI was extracted. Unwanted
      files were removed.
      
      The clang-format ignore list was updated to reflect the new source
      of files.
      
      test-repo-compengines.t was updated to reflect a change in behavior
      of the zstd library.
      
      The project contains a vendored copy of zstandard 1.4.3. The old
      version was 1.3.8. This should result in some minor performance wins.
      
      # no-check-commit because 3rd party code has different style guidelines
      
      Differential Revision: https://phab.mercurial-scm.org/D6858
      69de49c4e39c
  8. Sep 15, 2019
  9. Sep 14, 2019
  10. Sep 11, 2019
  11. Sep 13, 2019
  12. Sep 10, 2019
  13. Sep 09, 2019
  14. Sep 10, 2019
  15. Sep 11, 2019
  16. Sep 09, 2019
    • Connor Sheehan's avatar
      hgweb: fix websub regex flag syntax on Python 3 · 6ccf539aec71
      Connor Sheehan authored
      The `websub` config section for hgweb is broken under Python 3
      when using regex flags syntax (ie the optional `i` in the example
      from `hg help config.websub`:
      
          patternname = s/SEARCH_REGEX/REPLACE_EXPRESSION/[i]
      
      Flags are pulled out of the specified byte-string using a regular
      expression, and uppercased. The flags are then iterated over and
      passed to the `re` module using `re.__dict__[item]`, to get the
      object attribute of the same name from the `re` module. So on Python
      2 if the `il` flags are passed, this transition looks like:
      
          `'il'` -> `'IL'` -> `'I'` -> `re.__dict__['I']` -> `re.I`
      
      However on Python 3, these are bytes objects. When we iterate over
      a bytes object in Python 3, instead of getting the individual characters
      in the string as string objects of length one, we get the integer \
      value corresponding to that byte. So the same transition looks like:
      
          `b'il'` -> `b'IL'` -> `73` -> `re.__dict__[73]` -> `KeyError`
      
      This commit fixes the type mismatch by converting the bytes to a
      system string before iterating over each element to pass to `re`.
      The transition will now look like:
      
          `b'il'` -> `u'IL'` -> `u'I'` -> `re.__dict__[u'I']` -> `re.I`
      
      In addition we expand `test-websub.t` to cover the regex flag case
      (for both the `websub` section and `interhg`).
      
      Differential Revision: https://phab.mercurial-scm.org/D6788
      6ccf539aec71
    • Augie Fackler's avatar
      merge with stable · f059d6ffcdf0
      Augie Fackler authored
      f059d6ffcdf0
  17. Sep 07, 2019
  18. Sep 09, 2019
  19. Sep 07, 2019
  20. Dec 17, 2018
Loading