This instance will be upgraded to Heptapod 0.27.1 on 2021-12-08 at 22:00 UTC+1 (a few minutes of down time)

  1. 25 Nov, 2020 1 commit
  2. 24 Nov, 2020 3 commits
  3. 17 Nov, 2020 1 commit
  4. 16 Nov, 2020 1 commit
  5. 17 Nov, 2020 1 commit
    • Yuya Nishihara's avatar
      chgserver: backport py3 buffered I/O workarounds from procutil · b56feaa9b520
      Yuya Nishihara authored
      I've recently switched to new machine and I found chg's stdout is fully
      buffered.
      
      Even though chg server is a daemon process, it inherits the environment
      where the chg client originally forked the server. This means the server's
      stdout might have been wrapped by LineBufferedWrapper. That's why we need
      to do wrap/unwrap in both ways.
      
      The "if" condition in _restoreio() looks weird, but I'm not willing to
      clean things up because stdio behavior is fundamentally different between
      py2 and py3, and py2 support will be dropped anyway.
      b56feaa9b520
  6. 12 Nov, 2020 4 commits
  7. 10 Nov, 2020 1 commit
  8. 20 Oct, 2020 1 commit
  9. 22 Oct, 2020 1 commit
  10. 12 Oct, 2020 1 commit
  11. 22 Oct, 2020 1 commit
  12. 13 Nov, 2020 1 commit
    • Martin von Zweigbergk's avatar
      errors: catch urllib errors specifically instead of using safehasattr() · ae00e170f2d1
      Martin von Zweigbergk authored
      Before this patch, we would catch `IOError` and `OSError` and check if
      the instance had a `.code` member (indicates `HTTPError`) or a
      `.reason` member (indicates the more generic `URLError`). It seems to
      me that can simply catch those exception specifically instead, so
      that's what this code does. The existing code is from fbe8834923c5
      (commands: report http exceptions nicely, 2005-06-17), so I suspect
      it's just that there was no `urllib2` (where `URLError` lives) back
      then.
      
      The old code mentioned `SSLError` in a comment. The new code does
      *not* try to catch that. The documentation for `ssl.SSLError` says
      that it has a `.reason` property, but `python -c 'import ssl;
      print(dir(ssl.SSLError("foo", Exception("bar"))))` doesn't mention
      that property on either Python 2 or Python 3 on my system. It also
      seems that `sslutil` is pretty careful about converting `ssl.SSLError`
      to `error.Abort`. It also is carefult to not assume that instances of
      the exception have a `.reason`. So I at least don't want to catch
      `ssl.SSLError` and handle it the same way as `URLError` because that
      would likely result in a crash. I also wonder if we don't need to
      handle it at all (because `sslutil` might handle all the cases). It's
      now early in the release cycle, so perhaps we can just see how it
      goes?
      
      Differential Revision: https://phab.mercurial-scm.org/D9318
      ae00e170f2d1
  13. 12 Nov, 2020 1 commit
  14. 06 Nov, 2020 2 commits
  15. 11 Nov, 2020 1 commit
  16. 01 Sep, 2020 1 commit
  17. 10 Nov, 2020 1 commit
  18. 03 Nov, 2020 1 commit
  19. 06 Nov, 2020 1 commit
    • Gregory Szorc's avatar
      global: use python3 in shebangs · c102b704edb5
      Gregory Szorc authored
      Python 3 is the future. We want Python scripts to be using Python 3
      by default.
      
      This change updates all `#!/usr/bin/env python` shebangs to use
      `python3`.
      
      Does this mean all scripts use or require Python 3: no.
      
      In the test environment, the `PATH` environment variable in tests is
      updated to guarantee that the Python executable used to run
      run-tests.py is used. Since test scripts all now use
      `#!/usr/bin/env python3`, we had to update this code to install
      a `python3` symlink instead of `python`.
      
      It is possible there are some random scripts now executed with the
      incorrect Python interpreter in some contexts. However, I would argue
      that this was a pre-existing bug: we should almost always be executing
      new Python processes using the `sys.executable` from the originating
      Python script, as `python` or `python3` won't guarantee we'll use the
      same interpreter.
      
      Differential Revision: https://phab.mercurial-scm.org/D9273
      c102b704edb5
  20. 09 Nov, 2020 1 commit
  21. 22 Oct, 2020 1 commit
  22. 07 Oct, 2020 1 commit
  23. 22 Oct, 2020 1 commit
    • Martin von Zweigbergk's avatar
      errors: add config that lets user get more detailed exit codes · 21733e8c924f
      Martin von Zweigbergk authored
      This adds an experimental config that lets the user get more detailed
      exit codes. For example, there will be a specific error code for
      input/user errors. This is part of
      https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. I've made the
      config part of tweakdefaults.
      
      I've made the config enabled by default in tests. My reasoning is that
      we want to see that each specific error case gives the right exit code
      and we don't want to duplicate all error cases in the entire test
      suite. It also makes it easy to grep the `.t` files for `[255]` to
      find which cases we have left to fix. The logic for the current exit
      codes is quite simple, so I'm not too worried about regressions
      there. I've added a test case specifically for the "legacy" exit
      codes.
      
      I've set the detailed exit status only for the case of
      `InterventionRequired` and `SystemExit` for now (the cases where we
      currently return something other than 255), just to show that it
      works.
      
      Differential Revision: https://phab.mercurial-scm.org/D9238
      21733e8c924f
  24. 08 Nov, 2020 1 commit
    • Martin von Zweigbergk's avatar
      worker: raise exception instead of calling sys.exit() with child's code · 8f07f5a9c3de
      Martin von Zweigbergk authored
      When a worker process returns an error code, we would call
      `sys.exit()` with that exit code on the main process. The `SystemExit`
      exception would then get caught in `scmutil.callcatch()`, which would
      return that error code. The comment there says "Commands shouldn't
      sys.exit directly", which I agree with. This patch changes it so we
      raise a specific exception when a worker fails so we can catch
      instead. I think that means that `SystemExit` is now always an
      internal error.
      
      (I had earlier thought that this call to `sys.exit()` was from within
      the child process until Matt Harbison made me look again, so thanks
      for that!)
      
      Differential Revision: https://phab.mercurial-scm.org/D9287
      8f07f5a9c3de
  25. 03 Nov, 2020 1 commit
  26. 08 Nov, 2020 1 commit
  27. 07 Nov, 2020 1 commit
  28. 02 Nov, 2020 1 commit
  29. 31 Oct, 2020 1 commit
  30. 02 Nov, 2020 2 commits
  31. 29 Oct, 2020 3 commits