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