Skip to content
Snippets Groups Projects
  1. Jan 15, 2020
  2. Feb 05, 2020
  3. Jan 14, 2020
  4. Feb 05, 2020
  5. Jan 21, 2020
  6. Feb 05, 2020
  7. Jan 29, 2020
    • Kyle Lippincott's avatar
      chg: force-set LC_CTYPE on server start to actual value from the environment · 04a3ae7a
      Kyle Lippincott authored
      Python 3.7+ will "coerce" the LC_CTYPE variable in many instances, and this can
      cause issues with chg being able to start up. D7550 attempted to fix this, but a
      combination of a misreading of the way that python3.7 does the coercion and an
      untested state (LC_CTYPE being set to an invalid value) meant that this was
      still not quite working.
      
      This change will cause differences between chg and hg: hg will have the LC_CTYPE
      environment variable coerced, while chg will not. This is unlikely to cause any
      detectable behavior differences in what Mercurial itself outputs, but it does
      have two known effects:
      
      -   When using hg, the coerced LC_CTYPE will be passed to subprocesses, even
          non-python ones. Using chg will remove the coercion, and this will not
          happen. This is arguably more correct behavior on chg's part.
      -   On macOS, if you set your region to Brazil but your language to English,
          this isn't representable in locale strings, so macOS sets LC_CTYPE=UTF-8. If
          this value is passed along when ssh'ing to a non-macOS machine, some
          functions (such as locale.setlocale()) may raise an exception due to an
          unsupported locale setting. This is most easily encountered when doing an
          interactive commit/split/etc. when using ui.interface=curses.
      
      Differential Revision: https://phab.mercurial-scm.org/D8039
      04a3ae7a
  8. Feb 03, 2020
  9. Feb 01, 2020
  10. Dec 13, 2019
  11. Feb 04, 2020
  12. Feb 03, 2020
  13. Jan 31, 2020
  14. Jan 22, 2020
    • Martin von Zweigbergk's avatar
      merge: when rename was made on both sides, use ancestor as merge base · b4057d00
      Martin von Zweigbergk authored
      When both sides of a merge have renamed a file to the same place, we
      would treat that as a "both created" action in merge.py. That means
      that we'd use an empty diffbase. It seems better to use the copy
      source as diffbase. That can be done by simply dropping code that
      prevented us from doing that. I think I did it that way in
      57203e0210f8 (copies: calculate mergecopies() based on pathcopies(),
      2019-04-11) only to preserve the existing behavior. I also suspect it
      was just an accident that it behaved that way before that commit.
      
      Note that until fa9ad1da2e77 (merge: start using the per-side copy
      dicts, 2020-01-23), it was non-deterministic (depending on iteration
      order of the `allsources` set in `copies._fullcopytracing()`) which
      source was used in the affected test case in test-rename-merge1.t. We
      could easily have fixed that by sorting them, but now we can instead
      detect the case (the TODO added in the previous patch).
      
      Differential Revision: https://phab.mercurial-scm.org/D7974
      b4057d00
  15. Jan 31, 2020
  16. Feb 03, 2020
  17. Jan 29, 2020
  18. Jan 30, 2020
    • Jan Alexander Steffens (heftig)'s avatar
      worker: Use buffered input from the pickle stream · cb52e619
      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:
              os.close(rfd)
      
              for _ in range(4):
                  time.sleep(0.5)
                  print("First write")
                  os.write(wfd, obj_data[:10])
      
                  time.sleep(0.5)
                  print("Second write")
                  os.write(wfd, obj_data[10:])
      
              os._exit(0)
      
          try:
              os.close(wfd)
      
              rfile = os.fdopen(rfd, "rb", 0)
      
              print("Reading")
              while True:
                  try:
                      obj_copy = pickle.load(rfile)
                      assert obj == obj_copy
                  except EOFError:
                      break
              print("Success")
          finally:
              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.
      
      https://bugzilla.mozilla.org/show_bug.cgi?id=1604486
      
      Differential Revision: https://phab.mercurial-scm.org/D8051
      cb52e619
  19. Feb 01, 2020
  20. Feb 02, 2020
  21. Feb 01, 2020
    • Matt Harbison's avatar
      packaging: bundle dulwich, keyring, and pywin32-ctypes with WiX too · 481caa4a
      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
      481caa4a
    • Matt Harbison's avatar
      packaging: bundle the default mercurial.ini template with Inno also · a8786727
      Matt Harbison authored
      This is a step towards converging on the same installer content on Windows.
      
      Differential Revision: https://phab.mercurial-scm.org/D8061
      a8786727
    • Matt Harbison's avatar
      packaging: set the FileVersion field in the Inno installer executable · f37971c3
      Matt Harbison authored
      Previously, Properties > Details > File version showed "0.0.0.0".  This appears
      to be a longstanding issue, and not part of the refactoring this cycle.
      
      Differential Revision: https://phab.mercurial-scm.org/D8060
      f37971c3
    • Matt Harbison's avatar
      packaging: move the version normalization function to the util module · a70108a3
      Matt Harbison authored
      This will be used with Inno as well.  Since this module isn't platform specific,
      rename to include that this is meant for Windows.  (Mac has a different format.)
      
      Differential Revision: https://phab.mercurial-scm.org/D8059
      a70108a3
    • Matt Harbison's avatar
      resourceutil: account for the non-resource-like file hierarchy under py2exe · aab70b54
      Matt Harbison authored
      After 9e367157a990, config files for py2exe were expected to be in
      C:\Program Files\Mercurial\mercurial\defaultrc because of the implied resource
      structure of 'mercurial.defaultrc.*.rc', relative to the executable.
      Accomodating this would require changes to the WIX and Inno scripts (and perhaps
      the script that generates the WIX script), as well as 3rd party bundlers like
      TortoiseHg.  But these files aren't read as resources anyway- they fall back to
      the filesystem APIs.  (If we really wanted to carry on the charade, the
      installer would have to also sprinkle various empty __init__.py files around.)
      
      Instead, this simply prunes the 'mercurial.' portion of the resource name when
      run with py2exe.  (PyOxidizer uses the resources API, not the filesystem
      fallback, so it is unaffected.)  Since this hack only affects the py2 Windows
      installers and is less risky, I think it's reasonable.  We haven't needed to
      load any 3rd party resource up to this point, and would have to make packaging
      changes anyway to handle that.
      
      Differential Revision: https://phab.mercurial-scm.org/D8058
      aab70b54
  22. Jan 31, 2020
    • Matt Harbison's avatar
      wix: restore COPYING.rtf · f010a80e
      Matt Harbison authored
      This got truncated to 0 bytes in 0ab651b5f77c when the Phabricator extension
      crashed because it's a binary file.  That caused the license page in the WIX
      installer to be empty.  I don't remember if I needed to resubmit after the bug
      was fixed, so let's try this again with the current stable.  If this fails, I'll
      retry with 5.1 to see if this is a regression in the API changeover last cycle.
      
      Differential Revision: https://phab.mercurial-scm.org/D8052
      f010a80e
    • Matt Harbison's avatar
      resourceutil: correct the root path for file based lookup under py2exe · 9e367157
      Matt Harbison authored
      This silly copy/paste error caused "Mercurial" to be truncated from
      "C:\Program Files".  The fact that "helptext" and "defaultrc" are now in a
      subpackage of "mercurial" added it back on, and everything seemed to work.  But
      that broke if not installed to the default directory, and also caused TortoiseHg
      to look at Mercurial's config files instead of its own.
      
      Differential Revision: https://phab.mercurial-scm.org/D8054
      9e367157
  23. Jan 25, 2020
  24. Jan 23, 2020
  25. Jan 25, 2020
Loading