Skip to content
Snippets Groups Projects
  1. Nov 21, 2020
    • Matt Harbison's avatar
      extensions: gracefully warn when doing min version check with no local version · e402a45261db
      Matt Harbison authored
      After doing a `make clean`, I started getting cryptic failures to import
      extensions with the `minimumhgversion` attribute on py3:
      
          *** failed to import extension evolve: '>' not supported between instances of 'int' and 'NoneType'
          *** failed to import extension topic: '>' not supported between instances of 'int' and 'NoneType'
      
      This now handles the `(None, None)` tuple before comparing, and disables the
      extension with the same friendly message as in py2.
      
      Differential Revision: https://phab.mercurial-scm.org/D9363
      e402a45261db
  2. Nov 28, 2020
    • Yuya Nishihara's avatar
      diff: do not concatenate immutable bytes while building a/b bodies (issue6445) · 210f9b8d7bbd
      Yuya Nishihara authored
      Use bytearray instead. I don't know what's changed since Python 2, but bytes
      concatenation is 100x slow on Python 3.
      
        % python2.7 -m timeit -s "s = b''" "for i in range(10000): s += b'line'"
        1000 loops, best of 3: 321 usec per loop
      
        % python3.9 -m timeit -s "s = b''" "for i in range(10000): s += b'line'"
        5 loops, best of 5: 39.2 msec per loop
      
      Benchmark using tailwind.css (measuring the fast path, a is empty):
      
        % HGRCPATH=/dev/null python2.7 ./hg log -R /tmp/issue6445 -p --time \
        --color=always --config diff.word-diff=true >/dev/null
        (prev) time: real 1.580 secs (user 1.560+0.000 sys 0.020+0.000)
        (this) time: real 1.610 secs (user 1.570+0.000 sys 0.030+0.000)
      
        % HGRCPATH=/dev/null python3.9 ./hg log -R /tmp/issue6445 -p --time \
        --color=always --config diff.word-diff=true >/dev/null
        (prev) time: real 114.500 secs (user 114.460+0.000 sys 0.030+0.000)
        (this) time: real 2.180 secs (user 2.140+0.000 sys 0.040+0.000)
      
      Benchmark using random tabular text data (not the fast path):
      
        % dd if=/dev/urandom bs=1k count=1000 | hexdump -v -e '16/1 "%3u," "\n"' > ttf
        % hg ci -ma
        % dd if=/dev/urandom bs=1k count=1000 | hexdump -v -e '16/1 "%3u," "\n"' > ttf
        % hg ci -mb
      
        % HGRCPATH=/dev/null python2.7 ./hg log -R /tmp/issue6445 -p --time \
        --color=always --config diff.word-diff=true >/dev/null
        (prev) time: real 3.240 secs (user 3.040+0.000 sys 0.200+0.000
        (this) time: real 3.230 secs (user 3.070+0.000 sys 0.160+0.000)
      
        % HGRCPATH=/dev/null python3.9 ./hg log -R /tmp/issue6445 -p --time \
        --color=always --config diff.word-diff=true >/dev/null
        (prev) time: real 44.130 secs (user 43.850+0.000 sys 0.270+0.000)
        (this) time: real 4.170 secs (user 3.850+0.000 sys 0.310+0.000)
      210f9b8d7bbd
  3. Dec 01, 2020
  4. Nov 03, 2020
  5. Nov 02, 2020
  6. Oct 31, 2020
  7. Nov 02, 2020
  8. Oct 29, 2020
  9. Oct 24, 2020
    • Matt Harbison's avatar
      repoview: only pin obsolete wdir parents while there are unresolved conflicts · 341e014fe0fb
      Matt Harbison authored
      I noticed after doing an update from an obsolete revision with a dirty wdir that
      the obsolete commit stayed visible for no obvious reason.  It was decided in
      85b03b1e4715 not to clear mergestate once all of the conflicts were resolved, in
      order to allow re-resolving.  Since the point of pinning the obsolete parents
      was to allow resolving in the first place (aaeccdb6e654), it makes sense to also
      gate it on whether or not there are any remaining files to resolve.  This might
      result in pinning again if files are marked unresolved again, but that seems
      reasonable, given that it still solves the original issue.
      
      Note that this isn't purely cosmetic- pushing with a pinned obsolete revision is
      likely to cause complaints about pushing multiple heads or other unexpected
      errors.  So the faster it comes out of that state, the better.
      
      Differential Revision: https://phab.mercurial-scm.org/D9248
      341e014fe0fb
  10. Oct 28, 2020
  11. Oct 23, 2020
  12. Oct 29, 2020
  13. Oct 22, 2020
    • Matt Harbison's avatar
      demandimport: don't raise AttributeError if `exec_module` is missing · 8ed69bd42f10
      Matt Harbison authored
      I assume this was meant to do the check gracefully.  After shoveling a bunch of
      modules into the ignore list in order to get keyring to work out of the box on
      CentOS 8, I hit the following error accessing the password, which the change
      fixes.  Now the SecretStorage backend works out of the box, without any edits to
      the ignore list.
      
          ** Unknown exception encountered with possibly-broken third-party extension mercurial_keyring
          ** which supports versions unknown of Mercurial.
          ** Please disable mercurial_keyring and try your action again.
          ** If that fixes the bug please report it to https://foss.heptapod.net/mercurial/mercurial_keyring/issues
          ** Python 3.6.8 (default, Apr 16 2020, 01:36:27) [GCC 8.3.1 20191121 (Red Hat 8.3.1-5)]
          ** Mercurial Distributed SCM (version 5.5.2)
          ** Extensions loaded: evolve, topic, rebase, absorb, mercurial_keyring
          Traceback (most recent call last):
            File "/home/mharbison/hg_py3.6.8_venv/lib64/python3.6/site-packages/mercurial_keyring.py", line 230, in _read_password_from_keyring
              password = keyring.get_password(KEYRING_SERVICE, pwdkey)
            File "/home/mharbison/hg_py3.6.8_venv/lib64/python3.6/site-packages/keyring/core.py", line 53, in get_password
              return _keyring_backend.get_password(service_name, username)
            File "/home/mharbison/hg_py3.6.8_venv/lib64/python3.6/site-packages/keyring/backends/chainer.py", line 51, in get_password
              password = keyring.get_password(service, username)
            File "/home/mharbison/hg_py3.6.8_venv/lib64/python3.6/site-packages/keyring/backends/SecretService.py", line 79, in get_password
              return item.get_secret().decode('utf-8')
            File "/home/mharbison/hg_py3.6.8_venv/lib64/python3.6/site-packages/secretstorage/item.py", line 105, in get_secret
              decryptor = Cipher(aes, modes.CBC(aes_iv), default_backend()).decryptor()
            File "/home/mharbison/hg_py3.6.8_venv/lib64/python3.6/site-packages/cryptography/hazmat/backends/__init__.py", line 15, in default_backend
              from cryptography.hazmat.backends.openssl.backend import backend
            File "<frozen importlib._bootstrap>", line 971, in _find_and_load
            File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
            File "<frozen importlib._bootstrap>", line 665, in _load_unlocked
            File "/home/mharbison/hg_py3.6.8_venv/lib64/python3.6/site-packages/hgdemandimport/demandimportpy3.py", line 53, in exec_module
              self.loader.exec_module(module)
            File "/home/mharbison/hg_py3.6.8_venv/lib64/python3.6/site-packages/cryptography/hazmat/backends/openssl/__init__.py", line 7, in <module>
              from cryptography.hazmat.backends.openssl.backend import backend
            File "<frozen importlib._bootstrap>", line 971, in _find_and_load
            File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
            File "<frozen importlib._bootstrap>", line 665, in _load_unlocked
            File "/home/mharbison/hg_py3.6.8_venv/lib64/python3.6/site-packages/hgdemandimport/demandimportpy3.py", line 53, in exec_module
              self.loader.exec_module(module)
            File "/home/mharbison/hg_py3.6.8_venv/lib64/python3.6/site-packages/cryptography/hazmat/backends/openssl/backend.py", line 14, in <module>
              from six.moves import range
            File "<frozen importlib._bootstrap>", line 971, in _find_and_load
            File "<frozen importlib._bootstrap>", line 951, in _find_and_load_unlocked
            File "<frozen importlib._bootstrap>", line 894, in _find_spec
            File "/home/mharbison/hg_py3.6.8_venv/lib64/python3.6/site-packages/hgdemandimport/demandimportpy3.py", line 117, in find_spec
              and getattr(spec.loader, "exec_module")
          AttributeError: '_SixMetaPathImporter' object has no attribute 'exec_module'
      
      Differential Revision: https://phab.mercurial-scm.org/D9243
      8ed69bd42f10
    • Mitchell Plamann's avatar
    • Gregory Szorc's avatar
      automation: upload Python 3.9 Windows wheels · d1ce0ffdd3ce
      Gregory Szorc authored
      We are producing these. We should be publishing them.
      d1ce0ffdd3ce
    • Gregory Szorc's avatar
      contrib: split Windows requirements into multiple files · d270b9b797a7
      Gregory Szorc authored
      Package support for Python 2 has diverged significantly. It is no
      longer trivial to maintain a single requirements file that supports
      both Python 2 and 3 because the set of packages and versions varies
      wildly.
      
      This commit split up the Windows requirements files so we have
      variants for Python 2 and 3. As part of this, I also renamed the
      files to have what I believe to be more reasonable naming ("win32"
      felt like a weird identifier to me).
      
      We can see that some package versions decreated on 2.7. This is
      because the old pinned versions weren't compatible with Python 2.
      d270b9b797a7
  14. Oct 17, 2020
  15. Oct 19, 2020
  16. Oct 20, 2020
  17. Oct 16, 2020
  18. Oct 12, 2020
  19. Oct 05, 2020
  20. Oct 13, 2020
Loading