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
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
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
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
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
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
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
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
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
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
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
Augie Fackler <augie@google.com> [Sat, 07 Nov 2020 15:02:53 -0500] rev 45822
merge with stable
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Dan Villiom Podlaski Christiansen <danchr@gmail.com> [Mon, 26 Oct 2020 11:45:32 +0100] rev 45805
push: add --all-bookmarks option
Differential Revision: https://phab.mercurial-scm.org/D9261
Antoine cezar<acezar@chwitlabs.fr> [Thu, 29 Oct 2020 19:25:33 +0100] rev 45804
rhg: strip copied files metadata from `cat` output
Differential Revision: https://phab.mercurial-scm.org/D9264
Augie Fackler <augie@google.com> [Mon, 02 Nov 2020 14:39:43 -0500] rev 45803
merge with stable
Mathias De Mare <mathias.de_mare@nokia.com> [Mon, 02 Nov 2020 11:58:34 +0100] rev 45802
chg: close file descriptors when starting the daemon
It's good practice to close file descriptors when forking to start a daemon.
This did not appear to happen yet, which results in flock hanging
in one location in our system (because the chg daemon keeps
the locked file open).
Differential Revision: https://phab.mercurial-scm.org/D9268
Barret Rennie <barret@brennie.ca> [Sat, 31 Oct 2020 17:42:31 -0400] rev 45801
crecord: render chunkpad on Windows (
issue6427)
When using Windows wrappers of PDCurses (e.g., windows-curses), the chunkpad
does not render when executing `hg commit -i`. This is due to attempting to
refresh one too many columns of the pad.
Differential Revision: https://phab.mercurial-scm.org/D9267
Augie Fackler <raf@durin42.com> [Mon, 02 Nov 2020 14:26:19 -0500] rev 45800
Added signature for changeset
18c17d63fdab
Augie Fackler <raf@durin42.com> [Mon, 02 Nov 2020 14:26:18 -0500] rev 45799
Added tag 5.6 for changeset
18c17d63fdab
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Oct 2020 05:15:44 +0200] rev 45798
copies: make sure deleted copy info do not overwriting unrelated ones
See test documentation for details. This is yet another corner case for copy
tracing.
Differential Revision: https://phab.mercurial-scm.org/D9200
Joerg Sonnenberger <joerg@bec.de> [Wed, 21 Oct 2020 22:30:42 +0200] rev 45797
utils: helper function to print top memory allocation site
The memorytop function uses Python's tracemalloc module to show the
source lines / backtraces with the largest remaining allocations. This
allows identifying the origins of active memory by placing calls in
strategic locations. Allocations from C extensions will show up as long
as they are using the Python allocators.
Differential Revision: https://phab.mercurial-scm.org/D9236
Martin von Zweigbergk <martinvonz@google.com> [Thu, 29 Oct 2020 09:03:08 -0700] rev 45796
templates: include all non-branch namespaces in default one-line summary
I left out branches and custom namespaces on purpose from D9252
because I figured that people like us (Google) who have custom
namespaces can also have custom configs. However, I just realized that
this makes everyone with the topic extension lose the topic they've
had in rebase output for a long time (ever since someone was nice
enough to add it in D741). Sorry about the churn.
The more generic template couldn't easily keep the "log.bookmark"
label in the template because the namespace is called "bookmarks"
(plural). That means that we can't be compatible with users' existing
configs for "log.bookmark", so I decided to change the labels to be in
a brand-new "oneline-summary" namespace.
Differential Revision: https://phab.mercurial-scm.org/D9262
Joerg Sonnenberger <joerg@bec.de> [Thu, 29 Oct 2020 13:29:05 +0100] rev 45795
relnotes: mention improved memory use and underlaying API changes
Differential Revision: https://phab.mercurial-scm.org/D9258
Martin von Zweigbergk <martinvonz@google.com> [Thu, 29 Oct 2020 00:17:12 -0700] rev 45794
branching: merge with stable
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Oct 2020 21:57:21 +0900] rev 45793
help: update command synopsis to clarify "cp --forget" only takes destinations
I'm a bit confused while reading
03690079d7dd, which says "a destination
file", but the code loops over matched files.
Matt Harbison <matt_harbison@yahoo.com> [Tue, 13 Oct 2020 14:16:21 -0400] rev 45792
rebase: update commit hash references in the new commits
This excludes the --collapse case because degenerating to p1 is almost certainly
as wrong as leaving the old hashes in place. I expect most people to amend the
message explicitly when using that.
Differential Revision: https://phab.mercurial-scm.org/D9229
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Oct 2020 23:35:04 -0700] rev 45791
histedit: drop fallback to empty string from rendertemplate()
AFAICT, `cmdutil.rendertemplate()` always returns bytes (never
e.g. `None`), so we don't need to fall back to empty
(byte-)string. The fallback has been there since the code was added in
11c076786d56 (histedit: add templating support to histedit's rule file
generation, 2019-01-29).
Differential Revision: https://phab.mercurial-scm.org/D9244
Joerg Sonnenberger <joerg@bec.de> [Tue, 20 Oct 2020 17:32:45 +0200] rev 45790
phases: convert registernew users to use revision sets
Differential Revision: https://phab.mercurial-scm.org/D9233
Joerg Sonnenberger <joerg@bec.de> [Mon, 19 Oct 2020 02:54:12 +0200] rev 45789
phases: allow registration and boundary advancement with revision sets
The core internals either use revision sets already or can trivially use
them. Use the new interface in cg1unpacker.apply to avoid materializing
the list of all new nodes as it is normally just a revision range. This
avoids about 67 Bytes / changeset on AMD64 in peak RSS.
Differential Revision: https://phab.mercurial-scm.org/D9232
Joerg Sonnenberger <joerg@bec.de> [Sun, 18 Oct 2020 22:18:02 +0200] rev 45788
revlog: extend addgroup() with callback for duplicates
The addgroup() interface currently doesn't allow the caller to keep
track of duplicated nodes except by looking at the returned node list.
Add an optional second callback for this purpose and change the return
type to a boolean. This allows follow-up changes to use more efficient
storage for the node list in places that are memory-sensitive.
Differential Revision: https://phab.mercurial-scm.org/D9231
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 07 Oct 2020 14:26:47 +0530] rev 45787
tags: add safety check for len(record) while reading hgtagsfnodescache
I am trying to fix a breakage where somehow we end up getting a node of 12
length from `getfnode()`. Understanding the hgtagsfnodescache code, it seems
highly unlikely that it can happen unless one of `mctx.readfast().get()` or
`ctx.filenode()` is returning a node of 12 length.
For safety, I think it's better to add a check to make sure that record which we
are parsing is of same length we are expecting otherwise we consider that as
invalid record.
Differential Revision: https://phab.mercurial-scm.org/D9169
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 14 Oct 2020 17:52:18 +0200] rev 45786
procutil: allow to specify arbitrary stdin bytes to runbgcommand
For automatic clonebundles generation I need to pass arbitrary large amount of
data to the process (eg: common nodes, target nodes).
I am updating the `runbgcommand` to allow for this. Previously not stdin input
was possible, now, one can provide raw bytes and they will be feed to the
command through an unnamed temporary files.
Differential Revision: https://phab.mercurial-scm.org/D9212