Read about our upcoming Code of Conduct on this issue

  1. 09 Sep, 2020 1 commit
  2. 04 Oct, 2020 1 commit
    • Yuya Nishihara's avatar
      scmutil: move walkchangerevs() from cmdutil · 508dfd1c18df
      Yuya Nishihara authored
      It's no longer a command-level function, but a pure helper to walk revisions
      in a windowed way. This change will help eliminate reverse dependency of -> -> in future patches.
  3. 09 Sep, 2020 1 commit
  4. 13 Oct, 2020 2 commits
  5. 14 Oct, 2020 1 commit
    • Kyle Lippincott's avatar
      record: when backing up, avoid generating very long filenames · 9628d3cd9d13
      Kyle Lippincott authored
      If the original file's path is longer than the individual filename maximum
      length (256 on Linux, I believe?), then this mechanism of "replace slashes with
      underscores" causes an error.
      Now, we'll produce just the "basename" of the file, plus some stuff to ensure
      it's unique. This can be potentially confusing for users if there's a file with
      the same name in multiple directories, but I suspect that this is better than
      just breaking.
      `<reporoot>/a/long/path/to/somefile.txt` used to be backed up as
      `<reporoot>/.hg/record-backups/a_long_path_to_somefile.txt.abcdefgh`, it will
      now be backed up as `<reporoot>/.hg/record-backups/somefile.txt.abcdefgh`
      We could do the naive thing (what we were doing before) and have it to doing
      something with either subdirectories
      (`<backuproot>/a/long/path/to/somefile.txt.abcdefgh` or minimize #dirs with
      `<backuproot>/a_long_path/to_somefile.txt.abcdefgh`), prefix-truncated paths
      (such as `<backuproot>/__ath_to_somefile.txt.abcdefgh`, where that `__` elides
      enough to get us under 255 chars (counting the +9 we need to add!)), or
      hash-of-dirname (`<backuproot>/<sha1sum_of_dirname>/somefile.txt.abcdefgh`), but
      ultimately every option felt over engineered and that it would be more likely to
      cause problems than it would be to solve any, especially if it was conditional
      on directory length.
      Differential Revision:
  6. 10 Oct, 2020 1 commit
  7. 06 Oct, 2020 1 commit
  8. 09 Oct, 2020 4 commits
  9. 08 Oct, 2020 1 commit
  10. 10 Oct, 2020 4 commits
  11. 08 Oct, 2020 3 commits
  12. 09 Oct, 2020 1 commit
  13. 09 Sep, 2020 6 commits
  14. 08 Oct, 2020 1 commit
  15. 09 Oct, 2020 7 commits
  16. 08 Oct, 2020 1 commit
  17. 05 Oct, 2020 1 commit
    • Gregory Szorc's avatar
      pyoxidizer: produce working Python 3 Windows installers (issue6366) · 57b5452a55d5
      Gregory Szorc authored
      While we've had code to produce Python 3 Windows installers with
      PyOxidizer, we haven't been advertising them on the web site due to
      a bug in making TLS connections and issues around resource handling.
      This commit upgrades our PyOxidizer install and configuration to
      use a recent Git commit of PyOxidizer. This new version of PyOxidizer
      contains a *ton* of changes, improvements, and bug fixes. Notably,
      Windows shared distributions now mostly "just work" and the TLS bug
      and random problems with Python extension modules in the standard
      library go away. And Python has been upgraded from 3.7 to 3.8.6.
      The price we pay for this upgrade is a ton of backwards incompatible
      changes to Starlark.
      I applied this commit (the overall series actually) on stable to
      produce Windows installers for Mercurial 5.5.2, which I published
      shortly before submitting this commit for review.
      In order to get the stable branch working, I decided to take a
      less aggressive approach to Python resource management. Previously,
      we were attempting to load all Python modules from memory and were
      performing some hacks to copy Mercurial's non-module resources
      into additional directories in Starlark. This commit implements
      a resource callback function in Starlark (a new feature since
      PyOxidizer 0.7) to dynamically assign standard library resources
      to in-memory loading and all other resources to filesystem loading.
      This means that Mercurial's files and all the other packages we ship
      in the Windows installers (e.g. certifi and pygments) are loaded
      from the filesystem instead of from memory. This avoids issues
      due to lack of __file__ and enables us to ship a working Python
      3 installer on Windows.
      The end state of the install layout after this patch is not
      ideal for @: we still copy resource files like templates and
      help text to directories next to the hg.exe executable. There
      is code in @ to use importlib.resources to load these files and
      we could likely remove these copies once this lands on @. But for
      now, the install layout mimics what we've shipped for seemingly
      forever and is backwards compatible. It allows us to achieve the
      milestone of working Python 3 Windows installers and gets us a
      giant step closer to deleting Python 2.
      Differential Revision:
  18. 08 Oct, 2020 3 commits