Manuel Jacob <me@manueljacob.de> [Tue, 16 Jun 2020 12:59:45 +0200] rev 44813
py3: suppress DeprecationWarning about deprecated base64 module aliases
base64.encodestring() / base64.decodestring() were renamed to
base64.encodebytes() / base64.decodebytes() in Python 3. The old names still
worked, but raised a DeprecationWarning.
Manuel Jacob <me@manueljacob.de> [Mon, 15 Jun 2020 03:38:02 +0200] rev 44812
py3: use `pycompat.ziplist()`
Manuel Jacob <me@manueljacob.de> [Mon, 15 Jun 2020 03:34:23 +0200] rev 44811
py3: use `%d` for int in % formatting
On Python 3, `%s` is an alias to `%b`, which requires that the object implements
`__bytes__()`, which is not the case for `int`.
Manuel Jacob <me@manueljacob.de> [Mon, 15 Jun 2020 03:30:24 +0200] rev 44810
py3: fix bytes iteration
Manuel Jacob <me@manueljacob.de> [Mon, 15 Jun 2020 03:09:55 +0200] rev 44809
py3: unbyteify arguments to warnings.filterwarnings()
This fixes a crash when trying to import the convert extension on Python 3.
Anton Shestakov <av6@dwimlabs.net> [Sat, 06 Jun 2020 19:15:11 +0800] rev 44808
tests: adjust to the new format in pyflakes output
According to the pyflakes' NEWS.rst, the default output format changed
recently:
2.2.0 (2020-04-08)
- Include column information in error messages
So the lines now read:
contrib/perf.py:149:15 undefined name 'xrange'
mercurial/hgweb/server.py:427:13 undefined name 'reload'
mercurial/util.py:2862:24 undefined name 'file'
This is a graft of a similar fix that ended up on default.
Differential Revision: https://phab.mercurial-scm.org/D8630
Anton Shestakov <av6@dwimlabs.net> [Sat, 06 Jun 2020 19:12:49 +0800] rev 44807
tests: consistently use pyflakes as a Python module
We check availability of pyflakes as a module, and also running it for real as
a module. Only fair to test filterpyflakes.py working correctly when using
pyflakes as a module too.
This is a graft of a similar fix that ended up on default.
Differential Revision: https://phab.mercurial-scm.org/D8629
Anton Shestakov <av6@dwimlabs.net> [Sat, 06 Jun 2020 19:19:27 +0800] rev 44806
tests: skip pyflakes for mercurial/thirdparty/
The current version of pyflakes (2.2.0) correctly detects one issue:
mercurial/thirdparty/selectors2.py:335:40 '...'.format(...) has unused arguments at position(s): 1
But we're not interested in fixing lint errors in third-party code, so we need
to exclude at least selectors2.py. And in the discussion for this patch it was
decided to just skip the entire thirdparty directory.
This is a graft of a similar fix that ended up on default.
Differential Revision: https://phab.mercurial-scm.org/D8628
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 13 Jun 2020 11:06:22 +0200] rev 44805
zeroconf: fix non existant formatting in the vendored zeroconf module
On Tue Mar 1st 2016 at 09:33:39 timeless decided to wrap long line in
`hgext/zeroconf/Zeroconf.py`. Doing so, he fat fingered a "%w" instead of a "%s"
in a string. %w does not exists, 4 year later, pyflakes (rightfully) complains
about it. So I am fixing it.
Differential Revision: https://phab.mercurial-scm.org/D8627
Adam Hull <adam@hmlad.com> [Fri, 12 Jun 2020 14:22:34 -0700] rev 44804
ignore: note debugignore on ignore man page
It took me a long time to find debugignore. I found the ignore man page
quickly. This change adds a debugging section to the ignore man page
letting people know there is a debug command.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 13 Jun 2020 11:57:58 +0200] rev 44803
nodemap: fix validity checking when revlog is too short
We cannot check the nodeid of a revision that is not even there. We add a simple
fix and simple test.
Manuel Jacob <me@manueljacob.de> [Tue, 09 Jun 2020 05:24:45 +0200] rev 44802
resourceutil: fix location of line comments
These comments slipped out of position when the sources where formatted with
black in 2372284d9457.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 30 Apr 2020 00:33:00 -0400] rev 44801
rebase: avoid clobbering wdir() with --dry-run or --confirm (issue6291)
See 56d3e0b499df for the source of adding originalwd to the list of things that
cause wdir to be updated. That change didn't come with tests, and attempts to
recreate the scenario described have thus far failed.
Differential Revision: https://phab.mercurial-scm.org/D8489
Matt Harbison <matt_harbison@yahoo.com> [Thu, 30 Apr 2020 00:12:11 -0400] rev 44800
tests: show that rebase --dry-run and --confirm wipeout uncommitted changes
It looks like the carnage is limited to rebasing something that is not an
ancestor of wdir(), as both of these abort in a preflight check for that case
with a dirty working directory.
Differential Revision: https://phab.mercurial-scm.org/D8488
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 06 Jun 2020 00:51:36 +0530] rev 44799
Added signature for changeset 065704cbdbdb
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 06 Jun 2020 00:51:28 +0530] rev 44798
Added tag 5.4.1 for changeset 065704cbdbdb
Manuel Jacob <me@manueljacob.de> [Fri, 05 Jun 2020 06:40:15 +0200] rev 44797
py3: update comment to account for Python 2 and Python 3 differences
Manuel Jacob <me@manueljacob.de> [Fri, 05 Jun 2020 07:20:52 +0200] rev 44796
py3: add warning about buffering behavior of pycompat.{stdout,stderr}
Manuel Jacob <me@manueljacob.de> [Fri, 05 Jun 2020 04:10:37 +0200] rev 44795
tests: fix indentation
Yuya Nishihara <yuya@tcha.org> [Tue, 02 Jun 2020 20:40:06 +0900] rev 44794
graft: fix --base value to be saved in state file
'True' just works because it is treated as an integer revision '1' and
only the truthiness of the basectx is important. If multiple source revisions
were supported with --base, the resumed graft operation would go wrong.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:53 +0200] rev 44793
flags: also test merge with executable bit removed
This might catch more bug in the future.
Differential Revision: https://phab.mercurial-scm.org/D8536
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:42 +0200] rev 44792
flags: also test the removal of the exec flag
Differential Revision: https://phab.mercurial-scm.org/D8535
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:31 +0200] rev 44791
flags: read flag from dirstate/disk for workingcopyctx (issue5743)
In 491855ea9d62, various piece of code are moved from committablectx to
workingctx. The reason given is "These read from the dirstate, so they shouldn't
be used in other subclasses."
At least for `flags` this change introduce a bug, because the value flags end up being
read from `_manifest` disregarding the actual state in the working copy (ie: on
disk). When merging exec flag change with renames, this means a new files (the
local content, renamed) is properly written on disk, with the right flags, but
the flags part is later ignored when actually reading flags during merge.
It is not clear to me why the `flags` function was moved, because the code does
not actually hit the dirstate (the reason given in the changeset description).
So I am moving it back to were it comes from and we use a simpler version of
that code (that hit the dirstate everytime) in workingcopyctx. This fix the last
know bug with merging rename and executable byte changes.
Other similar bug might be lurking in 491855ea9d62, but I have not investigated
them.
Differential Revision: https://phab.mercurial-scm.org/D8534
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:19 +0200] rev 44790
flags: actually merge flags in simplemerge
Since b86fc43e4b73, the local flag were blindly taken. This resulted in bug when
rename are involved. exec flag change are now properly merged (when merged from
the rename side).
Another bug is affecting this when merging from the side without the rename.
Differential Revision: https://phab.mercurial-scm.org/D8533
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:07 +0200] rev 44789
flags: add a test for merging exec flag change with rename and file change
Changing the file activate other code path that also have bugs… There are two
distinct bugs depending of which side of the merge you stand on. They both
leading to exec flag loss.
We add tests for both, the fix are coming in later changesets.
Differential Revision: https://phab.mercurial-scm.org/D8532
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:37:56 +0200] rev 44788
flags: account for flag change when tracking rename relevant to merge
There are some logic filtering rename to the one relevant to the merge. That
logic was oblivious of flag change, leading to exec flag being dropped when
merged with a renamed.
There are two others bugs affecting this scenario. This patch fix the was where
there is not modification involved except for the flag change. Fixes for the
other bug are coming in later changesets.
Differential Revision: https://phab.mercurial-scm.org/D8531
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:37:44 +0200] rev 44787
flags: also test merging a rename with and exec flag change
This case is currently buggy and was not tested. This is probably a quite old
regression. The next changeset fix this case. Move exec+rename related bug will
gain a test later.
To highlight the expected behavior the currently missing line are marked with (false !)
and the bad one with (true !)
note: we should probably gain explicit "test bool" for this usecases.
Differential Revision: https://phab.mercurial-scm.org/D8530
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:37:33 +0200] rev 44786
flags: introduce explicit testing for merging change to exec flag
It turns out that we do not seems to test the simple case for merging exec flag
changes. More advanced case are test (merging exec flag without a common
ancestors, merging with a symlink, etc…) but not the basic.
We are about introduce various fixes to merging flag change across renames,
having the most basic case tested first seems useful.
note: We are only testing "adding" an exec flag here, not removing it. We
introduce basic test on stable and will consolidate them on default.
Differential Revision: https://phab.mercurial-scm.org/D8529
Charles Chamberlain <cchamberlain@janestreet.com> [Tue, 26 May 2020 11:14:07 -0400] rev 44785
graft-state: save --base in graft's state, fixing bug with graft --continue
Without this change, running graft --continue after grafting a merge commit using --base
(and encountering conflicts) will output "skipping ungraftable merge revision" even though
we specified a base in the initial graft command.
Graft's improve behaviour is reflected in test-graft.t.
Differential Revision: https://phab.mercurial-scm.org/D8578
Manuel Jacob <me@manueljacob.de> [Fri, 15 May 2020 00:53:37 +0200] rev 44784
setup: raise minimum Python version to 2.7.4
On older Python versions, Mercurial is not really usable because of
https://bugs.python.org/issue10211.
Recently someone reported a crash on the mailing list when running Mercurial
on Python 2.7.3. There was consensus that fixing compatibility for a Python
version more than 7 years old is not worth it. So, instead of making Mercurial
crash with an obscure exception, this patch raises the minimum Python version
to 2.7.4.
Connor Sheehan <sheehan@mozilla.com> [Tue, 19 May 2020 16:18:41 -0400] rev 44783
fsmonitor: coerce `clock` variable to byte-string (issue6321)
Callers of `fsmonitor.state.setlastclock` pass their arguments
wrapped in `pycompat.sysbytes` to ensure the value is a `bytes`
on Python 3. However in `fsmonitor.poststatus.__call__`, if the
return value of `getlastclock()` is `None`, we use the value of
`fsmonitor.poststatus._startclock` instead, which is not converted
to a byte string in the same manner. This commit converts the
value of `startclock` to a byte string using `pycompat.sysbytes`
in the constructor for `poststatus`, to avoid the "`str` + `bytes`"
error from issue 6321.
Differential Revision: https://phab.mercurial-scm.org/D8573
Charles Chamberlain <cchamberlain@janestreet.com> [Thu, 14 May 2020 23:14:24 -0400] rev 44782
py3: change default priority and length used for sorting hooks to be compatible with python 3
The call to `sorted(hooks.values())` can on line 213 of hooks.py can raise when using
python 3. For instance, when hooks.values is `[(0, 2, b'post-commit.check-status', b''),
(None, None, b'changegroup.app-hooks', <object object at 0x7f5279885590>)]`, the error is
`TypeError: '<' not supported between instances of 'NoneType' and 'int'`
This fix keeps the same order that was used in python 2 without relying on comparison with
None.
Differential Revision: https://phab.mercurial-scm.org/D8527
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 May 2020 08:31:32 -0700] rev 44781
relnotes: copy "next" to "5.4" and clear "next"
This is the same thing as we've done for the previous few releases.
Differential Revision: https://phab.mercurial-scm.org/D8546
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 May 2020 13:08:02 +0200] rev 44780
dirstate: make sure the dirstate is loaded before the changelog (issue6303)
Before this change, it was possible for the changelog to be loaded before the
dirstate. If a transaction happens betwen the changelog and dirstate reading,
the dirstate can up end poitning toward a revision not existing in the (olded)
changelog. This lead to a warning.
With this revision, we preload the dirstate parent before reading the changelog.
This has a negligible performance impact on performance for all case we are
tracking.
Differential Revision: https://phab.mercurial-scm.org/D8528
Raphaël Gomès <rgomes@octobus.net> [Mon, 11 May 2020 16:44:11 +0200] rev 44779
rust-dirstatemap: don't read the dirstate when requesting parents
A future patch for issue 6303 reveals a big performance regression in the Rust
`DirstateMap` that reads the entire dirstate when requesting parents instead
of the first 40 bytes.
`perfdiscovery` gets a *significant* speedup (from 0.101 to 0.016) when applied
against said patch.
I'm assuming it has other performance benefits, but this is already a good
enough win.
Differential Revision: https://phab.mercurial-scm.org/D8513
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Thu, 14 May 2020 10:24:52 -0400] rev 44778
py3: fix exception in pull when several things happen to a bookmark
Specifically, when `changes` is:
[(b'@upstream-committed', None, <function ui.status>, b'updating bookmark @upstream-committed\n'),
(b'@upstream-committed', binary-node, <function ui.warn>, b'divergent bookmark @ stored as @upstream-committed\n')]
sorting the list raises:
TypeError: '<' not supported between instances of 'bytes' and 'NoneType'
Differential Revision: https://phab.mercurial-scm.org/D8523
Joerg Sonnenberger <joerg@bec.de> [Tue, 12 May 2020 22:20:56 +0200] rev 44777
fastexport: adjust output to be more canonical
For time zones, git doesn't consider +0 and -0 the same timezone, so use
the former canonically. Add a test case to ensure that non-UTC offsets
are handled correctly. The real name part of the committer name is
normally not quoted, so don't enforce that.
Differential Revision: https://phab.mercurial-scm.org/D8522
Peter Arrenbrecht <peter@arrenbrecht.ch> [Mon, 11 May 2020 08:13:40 +0200] rev 44776
bash_completion: do not use aliased hg if it sources a script (issue6308)
I have an alias that sources a script around hg. Mercurial's bash_completion
script tries to use this as its main hg binary. But sourcing a wrapper breaks
Bash's completion. So this patch disables using the alias as the hg binary if
it starts with "source ".
Alias resolution was introduced in rev 191ab08e7099 for users with
"alias hg='hg --some_opts'".
See https://www.mercurial-scm.org/repo/hg/rev/191ab08e7099
Manuel Jacob <me@manueljacob.de> [Tue, 12 May 2020 01:03:12 +0200] rev 44775
demandimport: fix compatibility with meta path finders w/o find_spec() method
Meta path finders got a find_spec() method in Python version 3.4. The
sys.meta_path documentation says that the deprecated find_module() method is
used as a fallback.
Setuptool’s VendorImporter still doesn’t have the find_spec() method,
which resulted in a crash e.g. within a virtual environment. For reference, I
opened an issue for that: https://github.com/pypa/setuptools/issues/2104.
An alternative implementation would have been to implement a wrapper for
find_module() itself and raise an AttributeError when accessing find_spec() if
the wrapped finder doesn’t have it.
Joerg Sonnenberger <joerg@bec.de> [Thu, 07 May 2020 23:40:05 +0200] rev 44774
tests: fix timer scaling in wait-on-file
When using the default test timeouts, wait-on-file would not wait for $n
seconds, but $n/100 seconds. This resulted in easy timeouts on even
moderately busy fast machines. Fix the scaling to apply in all cases.
Adjust the stepping slightly to be nicer to systems with the historic
100Hz time base to ensure that the scheduler actually switches to a
different process and gives them time to work.
Differential Revision: https://phab.mercurial-scm.org/D8505
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 09 May 2020 20:25:07 +0200] rev 44773
manifest-cache: ignore IOError while writing
If the wcache directory is non writable for some reason (eg: belong to root).
Trying to write to it currently crash Mercurial. Instead we ignore the error and
skip writing that cache.
We should probably improve the user experience of multiple users interacting
with the same repository. However this is not an adventure for stable.
Differential Revision: https://phab.mercurial-scm.org/D8512
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 May 2020 11:40:17 -0700] rev 44772
copy: give better error message when no source paths found with --at-rev
The new error message matches what we show when marking copies in the
working copy.
Differential Revision: https://phab.mercurial-scm.org/D8496
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 May 2020 11:41:37 -0700] rev 44771
tests: show poor error message for `hg cp -A --at-rev . non-existent dst`
Differential Revision: https://phab.mercurial-scm.org/D8495
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 May 2020 10:33:56 -0700] rev 44770
copy: to find copy source, walk parent of revision we're marking copies in
As shown in the previous patch, `hg cp --after --at-rev . src dst`
fails if `src` is not in `.`. It seems obvious that you should always
walk the *parent* of the revision you're marking copies in, but that's
not how it was done for the working copy, and I didn't think to change
it when marking copies in a non-working-copy commit.
This patch fixes that by walking the parent commit instead, but only
if we're marking copies for a non-working-copy commit. We need to
leave the working-copy code unchanged because it depends on the weird
behavior of `workingctx.walk()`. With these changes, there's very
little overlap between the working-copy version and the
non-working-copy version of `walkpats()`, but I've refrained from
cleaning that up on the stable branch.
Differential Revision: https://phab.mercurial-scm.org/D8494
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 May 2020 11:41:01 -0700] rev 44769
tests: show that `hg cp -A --at-rev .` doesn't work for renames
I clearly forgot to implement (and test) support for marking of
renames when I added support for marking of copies :(
Differential Revision: https://phab.mercurial-scm.org/D8493
Raphaël Gomès <rgomes@octobus.net> [Fri, 08 May 2020 01:19:48 +0200] rev 44768
formatting: add missing newline
Differential Revision: https://phab.mercurial-scm.org/D8509
Joerg Sonnenberger <joerg@bec.de> [Mon, 27 Apr 2020 01:39:22 +0200] rev 44767
fastexport: downgrade message about already exported changesets to debug
The old warning level is just too noisy for incremental processing.
Differential Revision: https://phab.mercurial-scm.org/D8487
Matt Harbison <matt_harbison@yahoo.com> [Sun, 26 Apr 2020 14:29:47 -0400] rev 44766
url: fix a bytes vs str crash in processing proxy headers (issue6249)
I have no idea how to make a test for this, so if somebody knows, feel free to
add one or follow up on this. The bug reporter reported that it worked for
them, so there may not be other hidden issues here.
Differential Revision: https://phab.mercurial-scm.org/D8485
Joerg Sonnenberger <joerg@bec.de> [Fri, 24 Apr 2020 20:00:25 +0200] rev 44765
pullbundles: use unfiltered repo for head/base matching
The unfiltered view works even when changeset transistion from draft to
hidden phase. The normal visibility is already ensured by discovery as
invisible heads would have been filtered out before. Skipping the
filtering has a positive impact on performance, too.
Differential Revision: https://phab.mercurial-scm.org/D8481
Rodrigo Damazio Bovendorp <rdamazio@google.com> [Thu, 07 May 2020 03:14:52 -0700] rev 44764
procutil: always waiting on child processes to prevent zombies with 'hg serve'
When runbgcommand is invoked by an extension with ensurestart=False, we never
called waitpid - which is fine in most cases, except if that's happening on a
command server (e.g. chg), in which case the child defunct process will just
sit there for as long as the server is running.
The actual semantics of SIGCHLD signal handling is a lot more complex than
it seems, and the POSIX standard *seems* to read that it's ignored by default
and everything would just work without the waitpid if we're not listening for
it, but the truth is that it's only ignored if we *explicitly* set it to
SIG_IGN. We further cannot set it to SIG_IGN or to a catch-all handler across
all of 'hg serve', because Python's suprocess.Popen relies on that signal,
and a few specific parts of hg also set custom handlers, so instead we wait
for specific PIDs in dedicated threads.
I did a poor-man's benchmark of the thread creation and it seems to take
about 1ms, which is way better than the 20+ms from ensurestart=True.
Differential Revision: https://phab.mercurial-scm.org/D8497
Joerg Sonnenberger <joerg@bec.de> [Thu, 07 May 2020 15:00:33 +0200] rev 44763
tests: use regular POSIX shell
wait-on-file requires one POSIX extension (sleep with non-integral
argument), but it doesn't require any bash extensions, so just require a
normal POSIX shell. While here, use consistent formatting without
redundant ;
Differential Revision: https://phab.mercurial-scm.org/D8500
Raphaël Gomès <rgomes@octobus.net> [Thu, 07 May 2020 10:15:19 +0200] rev 44762
rust-regex: increase the DFA size limit for the `regex` crate
`re2`'s DFA limit is already increased in `rust/hg-core/src/re2/rust_re2.cpp`,
the same has to be done for the `regex` crate.
Big repositories with big `.hgignore`s will sometimes hit this limit and face
extreme performance regressions (I've seen one take *minutes* for `hg status`).
Differential Revision: https://phab.mercurial-scm.org/D8499
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 01 May 2020 21:47:39 +0530] rev 44761
Added signature for changeset cf3e07d7648a
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 01 May 2020 21:47:30 +0530] rev 44760
Added tag 5.4 for changeset cf3e07d7648a
Matt Harbison <matt_harbison@yahoo.com> [Thu, 16 Apr 2020 19:23:12 -0400] rev 44759
tests: clarify a comment describing a phabricator test scenario
Per review feedback.
Differential Revision: https://phab.mercurial-scm.org/D8455
Matt Harbison <matt_harbison@yahoo.com> [Thu, 16 Apr 2020 19:05:25 -0400] rev 44758
phabricator: ensure that `phabsend` is given a contiguous, linear commit range
Supplying a non-linear range was another orphan factory. While in theory there
could be a use case for skipping over garbage commits (like adding debugging)
and getting the valuable commits extracted out at the same time as posting a
review, it seems far more likely that specifying a non-linear range is a user
error. This is another case of issue6045, but predates both 0680b8a1992a and
601ce5392cb0.
Neither the `--no-amend` case nor resubmitting a previously submitted commit
would cause orphans. But for the sake of simplicity and to keep the parents
tracked on Phabricator in the proper state, ban missing commits unconditionally.
Differential Revision: https://phab.mercurial-scm.org/D8454
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 24 Apr 2020 12:37:43 -0700] rev 44757
automation: support building Python 3 MSI installers
This is very similar to what we just did for Inno.
Differential Revision: https://phab.mercurial-scm.org/D8484
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 24 Apr 2020 12:11:08 -0700] rev 44756
automation: support building Python 3 Inno installers
The core packaging code now supports building Python 3 installers
using PyOxidizer. Let's teach the automation code to invoke it so
that we produce both Python 2 and Python 3 based exe installers.
When publishing the artifacts, the Python 3 versions are preferred
over the Python 2 versions given their higher weight (10 versus 9).
This may be a controversial change. But I think making Python 3
the default is warranted, as it is the future. The Python 2 installers
are still fully supported and can be installed should issues with
Python 3 arise.
Differential Revision: https://phab.mercurial-scm.org/D8483
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 24 Apr 2020 11:48:07 -0700] rev 44755
automation: add extra arguments when building Inno
These were being fed into the template expansion but not being
used. This meant --version was not getting set when it should have
been.
Differential Revision: https://phab.mercurial-scm.org/D8482
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 23 Apr 2020 18:48:36 -0700] rev 44754
packaging: add -python2 to Windows installer filenames
We just taught the Windows installers to produce Python 3 variants
built with PyOxidizer.
Our plan is to publish both Python 2 and Python 3 versions of the
installers for Mercurial 5.4.
This commit teaches the Inno and WiX installers to add an optional
string suffix to the installer name. On Python 2, that suffix is
"-python2." We reserve the existing name for the Python 3 installers,
which we want to make the default.
Differential Revision: https://phab.mercurial-scm.org/D8479
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 23 Apr 2020 17:24:37 -0700] rev 44753
automation: support building Windows wheels for Python 3.7 and 3.8
The time has come to support Python 3 on Windows.
Let's teach our automation code to produce Windows wheels for
Python 3.7 and 3.8.
We could theoretically support 3.5 and 3.6. But I don't think
it is worth it. People on Windows generally use the Mercurial
installers, not wheels. And I'd prefer we limit variability
and not have to worry about supporting earlier Python versions
if it can be helped.
As part of this, we change the invocation of pip to `python.exe -m pip`,
as this is what is being recommended in Python docs these days. And
it seemed to be required to avoid a weird build error. Why, I'm not
sure. But it looks like pip was having trouble finding a Visual Studio
files when invoked as `pip.exe` but not when using `python.exe -m pip`.
Who knows.
Differential Revision: https://phab.mercurial-scm.org/D8478
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 20 Apr 2020 17:42:50 -0700] rev 44752
packaging: support building WiX installers with PyOxidizer
We initially implemented PyOxidizer support for Inno installers.
That did most of the heavy work of integrating PyOxidizer into
the packaging system. Implementing WiX installer support was
pretty straightforward.
Aspects of this patch look very similar to Inno's.
The main difference is the handling of the Visual C++
Redistributable Runtime files.
The WiX installer was formerly using merge modules to
install the VC++ 9.0 runtime because this feature is
supported by the WiX installer (it isn't easily available
to Inno installers).
Our strategy for the runtime files is to install the
vcruntime140.dll file next to hg.exe just like any other
file. While we could leverage WiX's functionality for invoking
a VCRedist installer, I don't want to deal with the complexity
at this juncture. So, we let run_pyoxidizer() copy vcruntime140.dll
into the staging directory (like it does for Inno) and our
dynamic WiX XML generator picks it up as a regular file and
installs it.
We did, however, have to teach mercurial.wxs how to conditionally
use the merge modules. But this was rather straightforward.
Comparing the file layout of the WiX installers before and
after:
* Various lib/*.{pyd, dll} files no longer exist
* python27.dll was replaced by python37.dll
* vcruntime140.dll was added
All these changes are expected due to the transition to
Python 3 and to PyOxidizer, which embeded the .pyd and .dll files
in hg.exe.
Differential Revision: https://phab.mercurial-scm.org/D8477
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 20 Apr 2020 18:24:35 -0700] rev 44751
packaging: move version derivation to run_wix_packaging()
With the previous commit moving signing inline, we no
longer need to compute the version string in build_installer()
and can instead move this logic to run_wix_packaging(). This
makes the logic in build_installer() simpler, which makes it
easier to implement alternate building mechanisms.
Differential Revision: https://phab.mercurial-scm.org/D8476
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 20 Apr 2020 17:53:20 -0700] rev 44750
packaging: integrate signing into run_wix_packaging()
Previously, signing was implemented via a separate function
which called build_installer() and then called signing
functionality.
In this model, in order to implement an alternative build
mechanism, we would have to invent a new variant to handle
signing as well.
This commit merges the signing logic into the function invoking
wix. If we pass an argument holding metadata about how to sign,
we sign hg.exe and the installer. This means all we have to
do is pass in signing info and the signing just works.
A slight change here is that signing of hg.exe happens in the
staging directory as opposed to before the staging directory
is populated. I don't think this matters.
Differential Revision: https://phab.mercurial-scm.org/D8475
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 20 Apr 2020 17:33:41 -0700] rev 44749
packaging: isolate invocation of WiX to own function
Like we did for Inno, we want to split out the building
of Mercurial from invoking the packaging tool so that we
can introduce an alternate build mechanism.
As part of this refactor, there are inconsequential changes
to file layouts. Before, some shared files such as the
WiX binaries and merge modules would be installed under
build/. Now, they are installed under build/wix-*. This
is to keep implementation simpler. But it also helps keep
build state more isolated.
Differential Revision: https://phab.mercurial-scm.org/D8474
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 23 Apr 2020 18:06:02 -0700] rev 44748
packaging: support building Inno installer with PyOxidizer
We want to start distributing Mercurial on Python 3 on
Windows. PyOxidizer will be our vehicle for achieving that.
This commit implements basic support for producing Inno
installers using PyOxidizer.
While it is an eventual goal of PyOxidizer to produce
installers, those features aren't yet implemented. So our
strategy for producing Mercurial installers is similar to
what we've been doing with py2exe: invoke a build system to
produce files then stage those files into a directory so they
can be turned into an installer.
We had to make significant alterations to the pyoxidizer.bzl
config file to get it to produce the files that we desire for
a Windows install. This meant differentiating the build targets
so we can target Windows specifically.
We've added a new module to hgpackaging to deal with interacting
with PyOxidizer. It is similar to pyexe: we invoke a build process
then copy files to a staging directory. Ideally these extra
files would be defined in pyoxidizer.bzl. But I don't think it
is worth doing at this time, as PyOxidizer's config files are
lacking some features to make this turnkey.
The rest of the change is introducing a variant of the
Inno installer code that invokes PyOxidizer instead of
py2exe.
Comparing the Python 2.7 based Inno installers with this
one, the following changes were observed:
* No lib/*.{pyd, dll} files
* No Microsoft.VC90.CRT.manifest
* No msvc{m,p,r}90.dll files
* python27.dll replaced with python37.dll
* Add vcruntime140.dll file
The disappearance of the .pyd and .dll files is acceptable, as
PyOxidizer has embedded these in hg.exe and loads them from
memory.
The disappearance of the *90* files is acceptable because those
provide the Visual C++ 9 runtime, as required by Python 2.7.
Similarly, the appearance of vcruntime140.dll is a requirement
of Python 3.7.
Differential Revision: https://phab.mercurial-scm.org/D8473
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 19 Apr 2020 15:35:21 -0700] rev 44747
packaging: split Inno installer building from Mercurial building
We want to make the logic for producing the installer agnostic about
how Mercurial is built to allow for alternate build methods (like
PyOxidizer).
Differential Revision: https://phab.mercurial-scm.org/D8472
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 19 Apr 2020 14:25:27 -0700] rev 44746
packaging: remove pyoxidizer.bzl from packaging directory
We have another version in rust/hgcli that is more modern
and is already associated with our Rust CLI project.
Differential Revision: https://phab.mercurial-scm.org/D8471
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 19 Apr 2020 14:16:24 -0700] rev 44745
contrib: install PyOxidizer in Linux and Windows environments
For Linux, this was trivial.
For Windows, we need to teach the powershell script to install
Rust as well. This was also pretty straightforward.
Differential Revision: https://phab.mercurial-scm.org/D8468
Elmar Bartel <elb_hg@leo.org> [Thu, 30 Apr 2020 15:10:05 +0200] rev 44744
diff: re-establish linear runtime performance
The previous method with sum() and list() creates a new list object
for every hunk. Then sum() is used to flatten out this sequence of
lists. The sum() function is not "lazy", but creates a new list object
for every "+" operation and so this code had quadratic runtime behaviour.
Raphaël Gomès <rgomes@octobus.net> [Thu, 23 Apr 2020 09:59:38 +0200] rev 44743
rust-status: check for '.hg' regardless of file type (issue6300)
'.hg' would show up in `hg status` if were a symlink.
Differential Revision: https://phab.mercurial-scm.org/D8461
Raphaël Gomès <rgomes@octobus.net> [Mon, 20 Apr 2020 11:03:31 +0200] rev 44742
rust: remove extra empty line
This is a gratuitous cleanup.
Differential Revision: https://phab.mercurial-scm.org/D8460
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Apr 2020 18:10:19 +0200] rev 44741
upgrade: properly filter action depending on planned work
The `determineactions` function filters out deficiency that are not scheduled to
be fixed by the target repository configuration. However it only did so for
requirement we currently support, letting other actions for unsupported
requirement through even if the target repo configuration did not request it.
As a result the output of the command was easily polluted by experimental
feature with no upgrade support.
We rework the code to still filter out requirement based action without the
faulty filtering.
Differential Revision: https://phab.mercurial-scm.org/D8427
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 13 Apr 2020 18:04:55 +0200] rev 44740
nodemap: skip persistent nodemap warming for revlog not using it
Before this patch, the usual checking (especially, inline-ess) were not
performed when warming the cache through `hg debugupdatecache`.
This is now fixed.
Differential Revision: https://phab.mercurial-scm.org/D8408
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Apr 2020 22:56:03 +0200] rev 44739
wait-on-file: adjust the timer counter
The wait performed in increment of 0.01 second, but the timer was expressed in
second. So we did not wait 20s, we waited 0.2 second. Internally we adjust the
counter to be expressed in centisecond. This prevent some flackyness in the
test.
Differential Revision: https://phab.mercurial-scm.org/D8453
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 19 Apr 2020 17:33:08 -0700] rev 44738
packaging: add docutils as dependency
The previous commit revealed that attempting to run
`python setup.py build_doc` from the packaging virtualenv
failed due to missing docutils package. We didn't notice
this before because py2exe Windows packaging appears to
use a Python from another virtualenv (which does include
docutils) to invoke setup.py. I discovered this as part
of implementing packaging outside of that virtualenv
environment.
Differential Revision: https://phab.mercurial-scm.org/D8470
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 19 Apr 2020 17:26:52 -0700] rev 44737
setup: use sysstr() on process output
Otherwise we get a str-bytes mismatch on Python 3 if
an error occurs.
Differential Revision: https://phab.mercurial-scm.org/D8469
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 28 Mar 2020 08:18:11 -0700] rev 44736
automation: install latest Python versions in Linux
Staying up to date. Keeping parity with the Windows environment.
Differential Revision: https://phab.mercurial-scm.org/D8467
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 21 Apr 2020 19:33:57 -0700] rev 44735
contrib: update to latest Python 2.7, 3.7, and 3.8
We would ideally update the 3.5 and 3.6 versions as well. But Python
didn't generate exe installers for newer versions for some reason.
Differential Revision: https://phab.mercurial-scm.org/D8466
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 19 Apr 2020 13:29:50 -0700] rev 44734
automation: always use latest Windows AMI
The old AMI isn't available any more.
We seem to run into this problem every few months. Amazon (or
Microsoft) appears to be removing the old AMIs when they are
superseded or something. Let's give up on tracking known images
and switch the image selection logic to use the latest published
image.
Differential Revision: https://phab.mercurial-scm.org/D8465
Matt Harbison <matt_harbison@yahoo.com> [Fri, 17 Apr 2020 21:00:18 -0400] rev 44733
tests: stabilize test-log.t on Windows
I think this is because Windows doesn't recognize single quote. Other ssh based
clones use this clunky style too.
Differential Revision: https://phab.mercurial-scm.org/D8459
Matt Harbison <matt_harbison@yahoo.com> [Fri, 17 Apr 2020 18:47:31 -0400] rev 44732
tests: stabilize test-convert-hg-source.t on Windows
This was a missing update in 1b8fd4af3318.
Differential Revision: https://phab.mercurial-scm.org/D8458
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 16 Apr 2020 22:55:41 +0530] rev 44731
Added signature for changeset 26ce8e751503
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 16 Apr 2020 22:55:40 +0530] rev 44730
Added tag 5.4rc0 for changeset 26ce8e751503
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 16 Apr 2020 22:51:09 +0530] rev 44729
merge default into stable for 5.4 release
Yuya Nishihara <yuya@tcha.org> [Thu, 16 Apr 2020 22:30:11 +0900] rev 44728
templatekw: fix shownames() to check if namespace exists in repo (issue6301)
Namespace registration is dynamic, but the corresponding template keyword
is registered statically.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Apr 2020 20:10:35 +0200] rev 44727
wait-on-file: use proper variable in math
This seems better and safer to be explicit.
Differential Revision: https://phab.mercurial-scm.org/D8426
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Apr 2020 20:08:36 +0200] rev 44726
wait-on-file: don't quote arithmetic argument
This is unnecessary and Mac OS X choke on them.
Differential Revision: https://phab.mercurial-scm.org/D8425
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Tue, 14 Apr 2020 19:09:56 -0400] rev 44725
graft: exit 1 on conflicts, like merge
It's more consistent, and makes it nicer to script around hg if you
don't have to ignore exit code 255, which is the error code for
basically everything in hg.
Differential Revision: https://phab.mercurial-scm.org/D8423
Joerg Sonnenberger <joerg@bec.de> [Fri, 10 Apr 2020 19:58:34 +0200] rev 44724
tests: deal with "ls" vs "ls -A" difference on 2BSD derived systems
BSD-derived systems will use "ls -A" when running as root. Adjust the
test cases to always use the flag and include .hg and related output as
appropiately.
Differential Revision: https://phab.mercurial-scm.org/D8397
Joerg Sonnenberger <joerg@bec.de> [Fri, 10 Apr 2020 19:53:36 +0200] rev 44723
tests: skip non-readable check for root
Trying to check for errors on non-readable hgrc requires UNIX
permissions, but still won't work for root. So adjust the check.
Differential Revision: https://phab.mercurial-scm.org/D8396
Joerg Sonnenberger <joerg@bec.de> [Fri, 10 Apr 2020 19:52:33 +0200] rev 44722
tests: skip CVS tests for root
It is not uncommon for cvs to check for root and to refuse work
in that case.
Differential Revision: https://phab.mercurial-scm.org/D8395
Matt Harbison <matt_harbison@yahoo.com> [Wed, 15 Apr 2020 22:18:05 -0400] rev 44721
make: drop the `-c` arg to `install` in the documentation makefile
This arg caused `gmake install` on OpenIndiana 2019.10 (illumos) fail with:
install: The -c, -f, -n options each require a directory following!
install: The -c, -f, -n options each require a directory following!
install: The -c, -f, -n options each require a directory following!
gmake[1]: *** [Makefile:41: install] Error 2
gmake[1]: Leaving directory '/usr/local/share/mercurial/doc'
The workaround is to run `gmake install-bin`.
The man page for 10.14 says this is to copy the file and is only for
compatability, as it is the default. The CentOS 7 man page says it is ignored.
The top level makefile doesn't use this argument at all, so I'm not sure why
it's here.
Differential Revision: https://phab.mercurial-scm.org/D8439
Matt Harbison <matt_harbison@yahoo.com> [Tue, 14 Apr 2020 18:51:23 -0400] rev 44720
phabricator: restack any new orphans created by phabsend (issue6045)
Previously, posting a new review for a non head commit would orphan the head.
The general case is any descendant of the selected revisions got orphaned if
this was the first time the selected revisions were submitted. It doesn't
happen when resubmitting. I've already had coworkers hit this a few times and
get confused. Since posting a review isn't generally thought of as an editing
operation, it would probably be easier for new users if we just restacked.
This avoids restacking existing orphans around the submission because that may
involve merge conflict resolution. Users who already have orphans should know
how to stabilize them anyway.
Differential Revision: https://phab.mercurial-scm.org/D8438
Matt Harbison <matt_harbison@yahoo.com> [Sun, 12 Apr 2020 13:11:42 -0400] rev 44719
phabricator: prevent posting obsolete commits
I don't see why this would be useful in the first place. But I had a coworker
submit a single commit that was not a branch head, and the result was to orphan
its child and keep the original commit visible. He then did up arrow + Enter,
and it happily created a new review (since the URL isn't amended into the
original commit specified on the command line) and a new successor, resulting in
a local divergence. I'd like to fix the issue with creating orphans, but this
is simple enough to prevent on its own.
Differential Revision: https://phab.mercurial-scm.org/D8437
Matt Harbison <matt_harbison@yahoo.com> [Tue, 03 Mar 2020 17:37:09 -0500] rev 44718
phabricator: avoid creating unstable children within the review stack
The instability occurred when rebasing something that has already been submitted
onto something that hasn't, and then resubmitting the stack. Or as the test
shows, just resubmitting and including something earlier that wasn't previously
submitted.
There's a general case here where any children (not just the ones in the range
of commits posted for review) should be re-stabilized. But handling the
selected commits here will cause the `local:commit` node values that are tracked
on Phabricator to be properly kept in sync.
Differential Revision: https://phab.mercurial-scm.org/D8436