Skip to content
Snippets Groups Projects
  1. Oct 22, 2020
  2. Nov 13, 2020
    • 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
  3. Nov 12, 2020
  4. Nov 06, 2020
  5. Nov 11, 2020
  6. Sep 01, 2020
  7. Nov 10, 2020
  8. Nov 03, 2020
  9. Nov 06, 2020
    • 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
  10. Nov 09, 2020
  11. Oct 22, 2020
  12. Oct 07, 2020
  13. Oct 22, 2020
    • 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
  14. Nov 08, 2020
    • 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
  15. Nov 03, 2020
  16. Nov 08, 2020
  17. Nov 07, 2020
  18. Oct 06, 2020
    • Gregory Szorc's avatar
      makefile: use Python 3 by default (BC) · c2837640aeb0
      Gregory Szorc authored
      This change is long overdue IMO.
      
      .. bc::
      
         Makefile now uses `python3` instead of `python` by default on
         non-Windows platforms. This means Mercurial will be built and
         run with Python 3 instead of Python 2.7 by default.
      
         To continue using Python 2, set the PYTHON variable. e.g.
         `make install PYTHON=python2.7`.
      
      Differential Revision: https://phab.mercurial-scm.org/D7258
      c2837640aeb0
  19. Nov 04, 2020
    • Martin von Zweigbergk's avatar
      hgweb: don't call sys.exit() in httpservice.run() · ee826f43cf4f
      Martin von Zweigbergk authored
      If I'm reading the code correctly, `mercurial.server.createservice()`
      can return an hgweb service or one of three types of command server
      services. The caller then calls `mercurial.server.runservice()`,
      passing it the returned service's run method. Only the hgweb service
      was calling `sys.exit()`. It has been that way since 8d44649df03b
      (refactor ssh server., 2006-06-04). That commit message doesn't
      provide any explanation. Let's clean up and have the code follow the
      usual return path into the `dispatch` module.
      
      After this patch, there should be no remaining places left where we
      call `sys.exit()` except for valid uses in the `dispatch` and `worker`
      modules.
      
      Differential Revision: https://phab.mercurial-scm.org/D9272
      ee826f43cf4f
  20. Nov 02, 2020
  21. Oct 31, 2020
  22. Nov 04, 2020
  23. Jun 23, 2020
    • Martin von Zweigbergk's avatar
      copies: handle more cases where a file got replaced by a copy · 58e7ee23ddbd
      Martin von Zweigbergk authored
      This patch fixes the changeset-centric version in a pretty
      straight-forward way. It fixes it to automatically resolve the
      conflict, which is better than resulting in a modify/delete conflict
      as it was before b4057d001760 (merge: when rename was made on both
      sides, use ancestor as merge base, 2020-01-22).
      
      I'll leave it for later to test and explicitly handle cases where
      files have been renamed to the same target on different sides of the
      merge.
      
      Differential Revision: https://phab.mercurial-scm.org/D8653
      58e7ee23ddbd
    • Martin von Zweigbergk's avatar
      tests: test more cases where a file got replaced by a copy · 4b79e92a5ef8
      Martin von Zweigbergk authored
      This adds a test where a file is modified on one branch and is renamed
      onto another file in another branch. That should ideally be
      automatically resolved (by propagating the modification to the rename
      destination). Alternatively, it could be considered a modify/delete
      conflict. It should at least not be automatically resolved by ignoring
      the modification. However, that is what actually happens with the
      changeset-centric algorithm since I broke it in b4057d001760 (merge:
      when rename was made on both sides, use ancestor as merge base,
      2020-01-22). Before that commit, it resulted in a modify/delete
      conflict. The filelog-centric algorithm was broken already before that
      commit.
      
      Differential Revision: https://phab.mercurial-scm.org/D8652
      4b79e92a5ef8
  24. Oct 07, 2020
  25. Oct 20, 2020
  26. Oct 29, 2020
    • Dan Villiom Podlaski Christiansen's avatar
      commit: warn the user when a commit already exists · 976b26bdd0d8
      Dan Villiom Podlaski Christiansen authored
      Sometimes, a commit will result in an exact match of a preexisting
      commit, and if that commit isn't a branch head, hg will incorrectly
      note that it created a new head. Instead, we should warn the user that
      commit already existed in the repository.
      
      In practice, this bug is rather uncommon, and will only occur when the
      usr explicitly sets the date.
      
      Please note that this commit contains an API change to
      cmdutil.commitstatus()
      
      Differential Revision: https://phab.mercurial-scm.org/D9257
      976b26bdd0d8
  27. Oct 06, 2020
    • Jörg Sonnenberger's avatar
      revlog: don't cache parsed tuples in the C module · 4404f129341e
      Jörg Sonnenberger authored
      A cached entry creates ~8 Python objects per cached changeset, which
      comes to around 200 Bytes per cached changeset on AMD64. Especially for
      operations that touch a lot of changesets, that can easily sum up to
      more than a 100MB of memory. Simple tests on large repositories show
      <2% runtime penalty for ripping out the cache, even for cache heavy
      operations like "hg log" for all revisions.
      
      Differential Revision: https://phab.mercurial-scm.org/D9155
      4404f129341e
  28. Oct 16, 2020
  29. Sep 28, 2020
  30. Oct 26, 2020
  31. Oct 29, 2020
  32. Nov 02, 2020
Loading