Fri, 06 Nov 2020 11:24:54 +0100 packaging: remove centos5 and centos6 support
Mathias De Mare <mathias.de_mare@nokia.com> [Fri, 06 Nov 2020 11:24:54 +0100] rev 45835
packaging: remove centos5 and centos6 support Differential Revision: https://phab.mercurial-scm.org/D9292
Wed, 11 Nov 2020 22:01:45 +0100 test-filecache: use sys.executable to call python
Mathias De Mare <mathias.de_mare@nokia.com> [Wed, 11 Nov 2020 22:01:45 +0100] rev 45834
test-filecache: use sys.executable to call python As was mentioned in c102b704edb5, test scripts calling 'python' or 'python3' might use the wrong python. For test-filecache.py, this causes a failed test on CentOS 7. Differential Revision: https://phab.mercurial-scm.org/D9295
Tue, 01 Sep 2020 11:03:47 -0400 make: add a pyoxidizer target
Augie Fackler <augie@google.com> [Tue, 01 Sep 2020 11:03:47 -0400] rev 45833
make: add a pyoxidizer target Differential Revision: https://phab.mercurial-scm.org/D9291
Tue, 10 Nov 2020 12:44:15 -0500 pyoxidizer: switch to modern config using run_command instead of run_mode
Augie Fackler <augie@google.com> [Tue, 10 Nov 2020 12:44:15 -0500] rev 45832
pyoxidizer: switch to modern config using run_command instead of run_mode Differential Revision: https://phab.mercurial-scm.org/D9290
Tue, 03 Nov 2020 16:25:33 -0500 pyoxidizer: default to one-file binary on non-Windows platforms
Augie Fackler <augie@google.com> [Tue, 03 Nov 2020 16:25:33 -0500] rev 45831
pyoxidizer: default to one-file binary on non-Windows platforms Windows has some extra constraints that require a multi-file install, but we expect folks to use an MSI or similar installer there so it's less of a big deal. Differential Revision: https://phab.mercurial-scm.org/D9289
Fri, 06 Nov 2020 13:58:59 -0800 global: use python3 in shebangs
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Nov 2020 13:58:59 -0800] rev 45830
global: use python3 in shebangs 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
Mon, 09 Nov 2020 09:58:44 -0800 tests: use python from environment in test-parseindex2.py
Martin von Zweigbergk <martinvonz@google.com> [Mon, 09 Nov 2020 09:58:44 -0800] rev 45829
tests: use python from environment in test-parseindex2.py Without this, the test starts failing with D9273 (the change to `pyexename` to be specific). Differential Revision: https://phab.mercurial-scm.org/D9286
Thu, 22 Oct 2020 13:38:14 -0700 errors: set detailed exit code to 20 for locking errors
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Oct 2020 13:38:14 -0700] rev 45828
errors: set detailed exit code to 20 for locking errors This is per https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. Differential Revision: https://phab.mercurial-scm.org/D9242
Tue, 06 Oct 2020 22:36:15 -0700 errors: introduce InputError and use it from commands and cmdutil
Martin von Zweigbergk <martinvonz@google.com> [Tue, 06 Oct 2020 22:36:15 -0700] rev 45827
errors: introduce InputError and use it from commands and cmdutil This patch introduces a `InputError` class and replaces many uses of `error.Abort` by it in `commands` and `cmdutil`. This is a part of https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. There will later be a different class for state errors (to raise e.g. when there's an unfinished operation). It's not always clear when one should report an input error and when it should be a state error. We can always adjust later if I got something wrong in this patch (but feel free to point out any you notice now). Differential Revision: https://phab.mercurial-scm.org/D9167
Wed, 21 Oct 2020 19:00:16 -0700 errors: add config that lets user get more detailed exit codes
Martin von Zweigbergk <martinvonz@google.com> [Wed, 21 Oct 2020 19:00:16 -0700] rev 45826
errors: add config that lets user get more detailed exit codes 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
Sat, 07 Nov 2020 21:50:28 -0800 worker: raise exception instead of calling sys.exit() with child's code
Martin von Zweigbergk <martinvonz@google.com> [Sat, 07 Nov 2020 21:50:28 -0800] rev 45825
worker: raise exception instead of calling sys.exit() with child's code 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
Tue, 03 Nov 2020 09:56:02 -0800 config: read system hgrc in lexicographical order
Martin von Zweigbergk <martinvonz@google.com> [Tue, 03 Nov 2020 09:56:02 -0800] rev 45824
config: read system hgrc in lexicographical order This is similar to edbcf5b239f9 (config: read configs from directories in lexicographical order, 2019-04-03). Apparently I forgot to sort the system hgrc files there. That's fixed by this patch. Differential Revision: https://phab.mercurial-scm.org/D9269
Sun, 08 Nov 2020 20:12:32 +0100 relnotes: drop 5.6 release entries from next
Joerg Sonnenberger <joerg@bec.de> [Sun, 08 Nov 2020 20:12:32 +0100] rev 45823
relnotes: drop 5.6 release entries from next Differential Revision: https://phab.mercurial-scm.org/D9282
Sat, 07 Nov 2020 15:02:53 -0500 merge with stable
Augie Fackler <augie@google.com> [Sat, 07 Nov 2020 15:02:53 -0500] rev 45822
merge with stable
Mon, 05 Oct 2020 19:46:31 -0700 makefile: use Python 3 by default (BC)
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 05 Oct 2020 19:46:31 -0700] rev 45821
makefile: use Python 3 by default (BC) 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
Tue, 03 Nov 2020 20:28:23 -0800 hgweb: don't call sys.exit() in httpservice.run()
Martin von Zweigbergk <martinvonz@google.com> [Tue, 03 Nov 2020 20:28:23 -0800] rev 45820
hgweb: don't call sys.exit() in httpservice.run() 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
Tue, 03 Nov 2020 20:20:49 -0800 serve: simply return instead of calling sys.exit() in `hg serve --stdio`
Martin von Zweigbergk <martinvonz@google.com> [Tue, 03 Nov 2020 20:20:49 -0800] rev 45819
serve: simply return instead of calling sys.exit() in `hg serve --stdio` The shouldn't be a reason to call `sys.exit()` instead of letting the code return normally. I've remove the call in both `hg serve` and `hg debugserve`. Differential Revision: https://phab.mercurial-scm.org/D9271
Tue, 03 Nov 2020 20:18:26 -0800 httpservice: move sys.exit() out of serve_forever()
Martin von Zweigbergk <martinvonz@google.com> [Tue, 03 Nov 2020 20:18:26 -0800] rev 45818
httpservice: move sys.exit() out of serve_forever() This is a simple refactoring to show the callers of the method, so it's easier to reason about the impact of removing the `sys.exit()` calls in subsequent patches. Differential Revision: https://phab.mercurial-scm.org/D9270
Mon, 22 Jun 2020 22:47:43 -0700 copies: handle more cases where a file got replaced by a copy
Martin von Zweigbergk <martinvonz@google.com> [Mon, 22 Jun 2020 22:47:43 -0700] rev 45817
copies: handle more cases where a file got replaced by a copy 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
Mon, 22 Jun 2020 22:47:33 -0700 tests: test more cases where a file got replaced by a copy
Martin von Zweigbergk <martinvonz@google.com> [Mon, 22 Jun 2020 22:47:33 -0700] rev 45816
tests: test more cases where a file got replaced by a copy 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
Wed, 07 Oct 2020 03:00:26 +0200 unionrepo: don't insert index tuples with None as int field
Joerg Sonnenberger <joerg@bec.de> [Wed, 07 Oct 2020 03:00:26 +0200] rev 45815
unionrepo: don't insert index tuples with None as int field None is not a valid size. Use -1 as placeholder instead. This will be necessary when the index starts enforcing type correctness. Differential Revision: https://phab.mercurial-scm.org/D9161
Wed, 07 Oct 2020 03:00:01 +0200 bundlerepo: don't insert index tuples with full nodes as linkrev
Joerg Sonnenberger <joerg@bec.de> [Wed, 07 Oct 2020 03:00:01 +0200] rev 45814
bundlerepo: don't insert index tuples with full nodes as linkrev The index format has a documented format and latter changes will start to enforce the field types. The bundlerepo uses full nodes for the linkrev field when it should be using revision numbers. Use the link mapping to resolve them, except in the special case of self-references. Those are actually indications of a missing linkrev. Differential Revision: https://phab.mercurial-scm.org/D9160
Tue, 20 Oct 2020 15:09:08 +0200 rhg: add full node id support for `debugdata` command
Antoine cezar<acezar@chwitlabs.fr> [Tue, 20 Oct 2020 15:09:08 +0200] rev 45813
rhg: add full node id support for `debugdata` command Unlike other later implemented commands `debugdata` only supported revision number. This changeset add full node id support for consistency with other commands. Differential Revision: https://phab.mercurial-scm.org/D9230
Thu, 29 Oct 2020 13:54:25 +0100 commit: warn the user when a commit already exists
Dan Villiom Podlaski Christiansen <danchr@gmail.com> [Thu, 29 Oct 2020 13:54:25 +0100] rev 45812
commit: warn the user when a commit already exists 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
Tue, 06 Oct 2020 13:34:51 +0200 revlog: don't cache parsed tuples in the C module
Joerg Sonnenberger <joerg@bec.de> [Tue, 06 Oct 2020 13:34:51 +0200] rev 45811
revlog: don't cache parsed tuples in the C module 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
Fri, 16 Oct 2020 16:00:32 -0700 fix: only check for obsolete commits in the --rev case
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Oct 2020 16:00:32 -0700] rev 45810
fix: only check for obsolete commits in the --rev case With both `--all` and `--source`, we already exclude obsolete revisions in the revset, so there's no need to call `checkfixablectx()` in those cases. Differential Revision: https://phab.mercurial-scm.org/D9227
Fri, 16 Oct 2020 15:02:46 -0700 fix: don't include obsolete descendants with -s
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Oct 2020 15:02:46 -0700] rev 45809
fix: don't include obsolete descendants with -s The `-s/--source` option is for regular users (`-r` is there for power users). If there are obsolete commits that are descendants of the given revision(s), then they almost definitely should just be left alone. That's what `hg rebase` does as well. So this patch makes it so we skip obsolete commits (including those in the input set itself). Differential Revision: https://phab.mercurial-scm.org/D9226
Fri, 16 Oct 2020 11:15:00 -0700 tests: add test showing how `hg fix -s` deals with obsolete and orphan nodes
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Oct 2020 11:15:00 -0700] rev 45808
tests: add test showing how `hg fix -s` deals with obsolete and orphan nodes We didn't have any tests for how `hg fix -s` behaves with obsolete commits among the descendants. The next patch will change the behavior in this area. Differential Revision: https://phab.mercurial-scm.org/D9225
Fri, 16 Oct 2020 15:05:43 -0700 fix: suggest --source instead of --rev on empty revset
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Oct 2020 15:05:43 -0700] rev 45807
fix: suggest --source instead of --rev on empty revset `--source` is the recommended flag for regular users (`--rev` is available for advanced users). Differential Revision: https://phab.mercurial-scm.org/D9224
Mon, 28 Sep 2020 17:13:15 +0200 hg-core: fix path encoding usage
Antoine cezar<acezar@chwitlabs.fr> [Mon, 28 Sep 2020 17:13:15 +0200] rev 45806
hg-core: fix path encoding usage 1. Hash encoded path are in `.hg/store/dh` instead of `.hg/store/data`. 2. Path encoded index and data files may not have the same parent path. It is not just about replacing `.i` by `.d` Differential Revision: https://phab.mercurial-scm.org/D9121
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 tip