1. 01 Mar, 2020 1 commit
    • Manuel Jacob's avatar
      branch: make --force work even when specifying revs · 92b7caf4cb9e
      Manuel Jacob authored
      The `hg branch` command accepts a `--force` parameter that allows to
      "set branch name even if it shadows an existing branch". However, before this
      patch, that didn’t work when specifying revs with `-r`.
      branch : stable
  2. 24 Feb, 2020 3 commits
    • Matt Harbison's avatar
      setup: exclude the __index__ module from itself when generating · bb58931d0c4f
      Matt Harbison authored
      This module is generated on Windows to hold all of the extension names and the
      help summaries, so that they are discoverable inside the py2exe zipfile.  The
      problem is this file is generated by dumping the disabled list, and that list
      comes from walking the filesystem.  So once an install from source into a
      virtualenv created this module, then next build from source from that virtualenv
      would also see __index__.py in the filesystem, and include it.  Clearly that's
      wrong because this isn't a real extension, so just filter it from the list when
      generating it.
      The Mercurial installer was unaffected by this, but the TortoiseHg package was.
      In the final package, `hg help -v extensions` and the panel of extensions both
      showed it.
      Differential Revision: https://phab.mercurial-scm.org/D8142
      branch : stable
    • Matt Harbison's avatar
      tests: stabilize test-amend.t on Windows · 1813f79017ac
      Matt Harbison authored
      If $TESTTMP isn't quoted in this context, it ends up like
      Differential Revision: https://phab.mercurial-scm.org/D8144
      branch : stable
    • Yuya Nishihara's avatar
      py3: fix EOL detection in commandserver.channeledinput · 98c14f0108b8
      Yuya Nishihara authored
      This breaks TortoiseHg's email preview which sends b'\n' while readline
      request is issued and the loop never ends. Spotted by Matt Harbison.
      branch : stable
  3. 21 Feb, 2020 2 commits
  4. 16 Feb, 2020 1 commit
  5. 18 Feb, 2020 1 commit
  6. 13 Dec, 2019 1 commit
  7. 12 Feb, 2020 1 commit
    • Raphaël Gomès's avatar
      rust-dirstatemap: add `NonNormalEntries` class · 71e13cfd6154
      Raphaël Gomès authored
      This fix introduces the same encapsulation as the `copymap`. There is no easy
      way of doing this any better for now.
      `hg up -r null && time HGRCPATH= HGMODULEPOLICY=rust+c hg up tip` on Mozilla
      Central, (not super recent, but it doesn't matter):
      Before: 7:44,08 total
      After: 1:03,23 total
      Pretty brutal regression!
      This is a graft on stable of cf1f8660e568
      Differential Revision: https://phab.mercurial-scm.org/D8111
      branch : stable
  8. 30 Jan, 2020 1 commit
    • Raphaël Gomès's avatar
      rust-dirstatemap: cache non normal and other parent set · 58c74a517a00
      Raphaël Gomès authored
      Performance of `hg update` was significantly worse since the introduction of
      the Rust `dirstatemap`. This regression was noticed by Valentin Gatien-Baron
      when working on a large repository, as it goes unnoticed for smaller
      repositories like Mercurial itself.
      This fix introduces the same getter/setter mechanism at `hg-core` level as
      for `set/get_dirs`.
      While this technique is, as previously discussed, quite suboptimal, it fixes an
      important enough problem. Refactoring `hg-core` to use the typestate
      pattern could be a good approach to improving code quality in a future patch.
      This is a graft of stable of 83b2b829c94e
      Differential Revision: https://phab.mercurial-scm.org/D8110
      branch : stable
  9. 11 Feb, 2020 1 commit
    • Yuya Nishihara's avatar
      chgserver: spawn new process if schemes change · 5cd2d91eeebd
      Yuya Nishihara authored
      The schemes extension updates hg.schemes table. It's technically possible
      for hg.repository() to look for e.g. ui.schemes instead of depending on
      module-local table, but I don't think the change would make much sense
      since [schemes] is usually specified in ~/.hgrc and thus it can be considered
      static data.
      branch : stable
  10. 10 Feb, 2020 2 commits
  11. 01 Feb, 2020 1 commit
  12. 09 Feb, 2020 1 commit
    • Pierre-Yves David's avatar
      remotefilelog-test: glob some flaky output line (issue6083) · ee0959e7d435
      Pierre-Yves David authored
      The two following lines are flaky underload, yet the final result is correct.
      The command involves background pre-check of output, these are not stable
      probably because they run in parallel in multiple process.
      I spent a couple of hours trying to understand the pattern and gave up. The
      documented intend of these tests is safely guaranteed by checking the cache
      content after the command.
      If it become useful to start testing precise internal details of the, they will
      have to be tested in a more appropriate framework than `.t` tests.
      Differential Revision: https://phab.mercurial-scm.org/D8102
      branch : stable
  13. 03 Feb, 2020 1 commit
  14. 06 Feb, 2020 1 commit
    • Kyle Lippincott's avatar
      py3: fully fix bundlepart.__repr__ to return str not bytes · 74172a234dd3
      Kyle Lippincott authored
      My previous fix did not fully fix the issue: it would attempt to use
      %-formatting to combine two strs into a bytes, which won't work. Let's just
      switch the entire function to operating in strs. This can cause a small output
      difference that will likely not be noticed since no one noticed that the method
      wasn't working at all before: if `id` or `type` are not-None, they'll be shown
      as `b'val'` instead of `val`. Since this is a debugging aid and these strings
      shouldn't be shown to the user, slightly rough output is most likely fine and
      it's likely not worthwhile to add the necessary conditionals to marginally
      improve it.
      Differential Revision: https://phab.mercurial-scm.org/D8091
      branch : stable
  15. 17 Nov, 2019 1 commit
  16. 16 Nov, 2019 1 commit
  17. 25 Jan, 2020 1 commit
  18. 18 Nov, 2019 1 commit
  19. 16 Nov, 2019 1 commit
  20. 24 Jan, 2020 1 commit
  21. 25 Jan, 2020 1 commit
    • Pierre-Yves David's avatar
      heptapod-ci: add a basic file to be able to run tests with heptapod · 8b1dd3f42396
      Pierre-Yves David authored
      Having this yaml file somewhere in the main mercurial repository makes it
      trivial for contributors using heptapod to run CI on their in-progress work.
      There are alot of different combination (python2/python3 pure/cext/rust/pypy)
      to be tested and making sure all of them are covered manually is cumbersome.
      Automatic CI runnig on draft really helps in that matters. We start small bu
      later changesets will add more step testing more of the variants.
      The series is targetted on stable to make it available to the widest amount of contribution possible.
      The definition of the docker files used for this are available here:
      Differential Revision: https://phab.mercurial-scm.org/D8011
      branch : stable
  22. 04 Feb, 2020 1 commit
    • Jan Alexander Steffens (heftig)'s avatar
      worker: manually buffer reads from pickle stream · 12491abf93bd
      Jan Alexander Steffens (heftig) authored
      My previous fix (D8051, cb52e619c99e, which added Python's built-in buffering
      to the pickle stream) has the problem that the selector will ignore the buffer.
      When multiple pickled objects are read from the pipe into the buffer at once,
      only one object will be loaded.
      This can repeat until the buffer is full and delays the processing of completed
      items until the worker exits, at which point the pipe is always considered
      readable and all remaining items are processed.
      This changeset reverts D8051, removing the buffer again. Instead, on Python 3
      only, we use a wrapper to modify the "read" provided to the Unpickler to behave
      more like a buffered read. We never read more bytes from the pipe than the
      Unpickler requests, so the selector behaves as expected.
      Also add a test case for "pickle data was truncated" issue.
      Differential Revision: https://phab.mercurial-scm.org/D8076
      branch : stable
  23. 02 Jan, 2020 1 commit
  24. 04 Feb, 2020 2 commits
  25. 03 Feb, 2020 1 commit
  26. 04 Feb, 2020 2 commits
  27. 03 Feb, 2020 2 commits
  28. 29 Jan, 2020 1 commit
    • Raphaël Gomès's avatar
      rust-dirstatemap: add missing @propertycache · 7f5410dfc8a6
      Raphaël Gomès authored
      While investigating a regression on `hg update` performance introduced by the
      Rust `dirstatemap`, two missing `@propertycache` were identified when comparing
      against the Python implementation. This adds back the first one, that has
      no observable impact on behavior. The second one (`nonnormalset`) is going to
      be more involved, as the caching has to be done from the Rust side of things.
      Differential Revision: https://phab.mercurial-scm.org/D8047
      branch : stable
  29. 30 Jan, 2020 1 commit
    • Jan Alexander Steffens (heftig)'s avatar
      worker: Use buffered input from the pickle stream · cb52e619c99e
      Jan Alexander Steffens (heftig) authored
      On Python 3, "pickle.load" will raise an exception ("_pickle.UnpicklingError:
      pickle data was truncated") when it gets a short read, i.e. it receives fewer
      bytes than it requested.
      On our build machine, Mercurial seems to frequently hit this problem while
      updating a mozilla-central clone iff it gets scheduled in batch mode. It is easy
      to trigger with:
          #wipe the workdir
          rm -rf *
          hg update null
          chrt -b 0 hg update default
      I've also written the following program, which demonstrates the core problem:
          from __future__ import print_function
          import io
          import os
          import pickle
          import time
          obj = {"a": 1, "b": 2}
          obj_data = pickle.dumps(obj)
          assert len(obj_data) > 10
          rfd, wfd = os.pipe()
          pid = os.fork()
          if pid == 0:
              for _ in range(4):
                  print("First write")
                  os.write(wfd, obj_data[:10])
                  print("Second write")
                  os.write(wfd, obj_data[10:])
              rfile = os.fdopen(rfd, "rb", 0)
              while True:
                      obj_copy = pickle.load(rfile)
                      assert obj == obj_copy
                  except EOFError:
              os.kill(pid, 15)
      The program reliably fails with Python 3.8 and succeeds with Python 2.7.
      Providing the unpickler with a buffered reader fixes the issue, so let
      "os.fdopen" create one.
      Differential Revision: https://phab.mercurial-scm.org/D8051
      branch : stable
  30. 01 Feb, 2020 1 commit
  31. 02 Feb, 2020 1 commit
  32. 01 Feb, 2020 2 commits
    • Matt Harbison's avatar
      packaging: bundle dulwich, keyring, and pywin32-ctypes with WiX too · 481caa4a2244
      Matt Harbison authored
      TortoiseHg installs these, which is possibly where they originated (though I
      would have thought it more likely to be in the WiX installer, given its
      heritage).  When I was working on the TortoiseHg app for Mac (which uses the
      similar `py2app`), it wasn't possible to use the keyring extension (even
      externally) without bundling this keyring package into the app.  Assuming the
      same principle applies here, these would enable some common extensions.  One of
      the things that the TortoiseHg packager on macOS does now is it adds the user's
      local `site-packages` directory to `sys.path`.  That would allow the user to
      install these critical modules in cases like this.  But that can probably wait
      for py3 packaging.
      The only difference in the installed packages that I see now is WiX also bundles
      distutils for some reason.  I suppose that's not harming anything, so I'm not
      touching it.
      The only orphans in the install directories when comparing WiX and Inno now is
      the Copying.txt vs COPYING.rtf, the two uninstaller files for Inno, and a
      `Mercurial.url` file in Inno.  I have no idea what that is, and it has *.ini
      syntax with a single field pointing to the Mercurial homepage.
      Differential Revision: https://phab.mercurial-scm.org/D8062
      branch : stable
    • Matt Harbison's avatar
      packaging: bundle the default mercurial.ini template with Inno also · a8786727e478
      Matt Harbison authored
      This is a step towards converging on the same installer content on Windows.
      Differential Revision: https://phab.mercurial-scm.org/D8061
      branch : stable