- Nov 28, 2020
-
-
Pierre-Yves David authored
If a changeset have been submitted to Phabricator and a new version is pushed to heptapod, we should refresh the state on Phabricator. If we do not do this, they are a risk of an older version being applied from Phabricator. In this situation content-divergence will be (rightfully) detected by evolution. We only refresh the Diff if the test pass, to avoid updating Phabricator with broken content. Differential Revision: https://phab.mercurial-scm.org/D9451
-
Pierre-Yves David authored
This will be useful to introduce automatic refresh through heptapod. Differential Revision: https://phab.mercurial-scm.org/D9460
-
- Nov 30, 2020
-
-
Mathias De Mare authored
Before this change, packaging on CentOS 8 failed because 'python' is used instead of 'python3'. Change was tested with: - make docker-centos7 - make docker-centos8 - make docker-ubuntu-bionic Differential Revision: https://phab.mercurial-scm.org/D9464
-
- Nov 26, 2020
-
-
Matt Harbison authored
This is needed to be able to use the git extension. The extension no longer complains about the library being not installed, but `hg log -r .` on a repo that works in WSL yielded a TypeError: ... File "mercurial.hg", line 188, in _peerorrepo File "mercurial.localrepo", line 3224, in instance File "mercurial.localrepo", line 623, in makelocalrepository File "hgext.git", line 117, in _makestore File "hgext.git", line 48, in __init__ TypeError: Repository unable to unpack backend. Differential Revision: https://phab.mercurial-scm.org/D9405
-
- Nov 24, 2020
-
-
Matt Harbison authored
Disco support ended in January 2020, and Focal does not have an announced EOL. Something is now installing and configuring `tzdata`, which was throwing up an interactive prompt to configure the timezone. Aside from being hostile to automation, the prompt didn't actually accept input and hung the process. This propagates the host's timezone into the image via environment variable in order to skip the prompt, and avoid hardcoding a value. Differential Revision: https://phab.mercurial-scm.org/D9396
-
Matt Harbison authored
I was getting build failures when it was trying to write to the working directory on CentOS 7 without this. It is basically the same as was added to the RPM builder in 4c0d4bbdc395. For some reason, this doesn't work with Xenial, and the only solution I found was to invoke it with UID 1000 on the host side. It doesn't EOL until April 2024, but it also has python 3.5.2, so this build complication is the least of the problems with supporting it after py2 is dropped. Differential Revision: https://phab.mercurial-scm.org/D9394
-
- Nov 29, 2020
-
-
Pierre-Yves David authored
Otherwise, checks and script relying on some changeset being draft fails. Differential Revision: https://phab.mercurial-scm.org/D9461
-
- Nov 28, 2020
-
-
Pierre-Yves David authored
We are about to add more stage Differential Revision: https://phab.mercurial-scm.org/D9454
-
- Nov 27, 2020
-
-
durin42 authored
This required a couple of small tweaks to un-confuse black, but now it works. Big formatting changes come from: * Dramatically improved collection-splitting logic upstream * Black having a strong (correct IMO) opinion that """ is better than ''' Differential Revision: https://phab.mercurial-scm.org/D9430
-
- Nov 11, 2020
-
-
Mathias De Mare authored
Test on CentOS 7, repository with ~170000 tracked files, no untracked files: 10 runs with this enabled: -- Run #0 time: 0.6519973278045654 -- Run #1 time: 0.6933724880218506 -- Run #2 time: 0.7512078285217285 -- Run #3 time: 0.7517638206481934 -- Run #4 time: 0.5966529846191406 -- Run #5 time: 0.5960886478424072 -- Run #6 time: 0.5940573215484619 -- Run #7 time: 0.5963726043701172 -- Run #8 time: 0.6048009395599365 -- Run #9 time: 0.603604793548584 10 runs without this enabled: -- Run #0 time: 2.127584457397461 -- Run #1 time: 2.066192865371704 -- Run #2 time: 2.0831892490386963 -- Run #3 time: 2.077716588973999 -- Run #4 time: 2.07608962059021 -- Run #5 time: 2.072899341583252 -- Run #6 time: 2.094369888305664 -- Run #7 time: 2.067504644393921 -- Run #8 time: 2.069610834121704 -- Run #9 time: 2.0567898750305176 Differential Revision: https://phab.mercurial-scm.org/D9294
-
- Nov 26, 2020
-
-
Matt Harbison authored
SecretStorage is a Linux package, and the other stuff removed is a dependency of it. I assume this was last generated on Linux, and noticed this trying to add another package and regenerating on Windows. Differential Revision: https://phab.mercurial-scm.org/D9404
-
- Nov 25, 2020
-
-
Augie Fackler authored
When doing some work involving one-file binaries, this line is failing for me. It seems reasonable to just make sure the destination directory exists before splatting the file into it. Differential Revision: https://phab.mercurial-scm.org/D9401
-
- Nov 22, 2020
-
-
Pulkit Goyal authored
Differential Revision: https://phab.mercurial-scm.org/D9365
-
- Nov 20, 2020
-
-
Georges Racinet authored
We are now touching the rate limits of Docker Hub.
-
- Nov 06, 2020
-
-
Mathias De Mare authored
Differential Revision: https://phab.mercurial-scm.org/D9293
-
Mathias De Mare authored
Differential Revision: https://phab.mercurial-scm.org/D9292
-
Gregory Szorc authored
Python 3 is the future. We want Python scripts to be using Python 3 by default. This change updates all `#!/usr/bin/env python` shebangs to use `python3`. Does this mean all scripts use or require Python 3: no. In the test environment, the `PATH` environment variable in tests is updated to guarantee that the Python executable used to run run-tests.py is used. Since test scripts all now use `#!/usr/bin/env python3`, we had to update this code to install a `python3` symlink instead of `python`. It is possible there are some random scripts now executed with the incorrect Python interpreter in some contexts. However, I would argue that this was a pre-existing bug: we should almost always be executing new Python processes using the `sys.executable` from the originating Python script, as `python` or `python3` won't guarantee we'll use the same interpreter. Differential Revision: https://phab.mercurial-scm.org/D9273
-
- Nov 02, 2020
-
-
Mathias De Mare authored
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
-
- Oct 22, 2020
-
-
Gregory Szorc authored
We are producing these. We should be publishing them.
-
Gregory Szorc authored
Package support for Python 2 has diverged significantly. It is no longer trivial to maintain a single requirements file that supports both Python 2 and 3 because the set of packages and versions varies wildly. This commit split up the Windows requirements files so we have variants for Python 2 and 3. As part of this, I also renamed the files to have what I believe to be more reasonable naming ("win32" felt like a weird identifier to me). We can see that some package versions decreated on 2.7. This is because the old pinned versions weren't compatible with Python 2.
-
- Oct 19, 2020
-
-
Gregory Szorc authored
We were previously using a Git commit from a few days before the 0.8 release. This commit upgrades us to the just-released 0.9 release. This required some Starlark changes due to backwards incompatible changes. Differential Revision: https://phab.mercurial-scm.org/D9228
-
- Oct 09, 2020
-
-
Gregory Szorc authored
We just added CPython 3.9.0 to the automation environment. Let's support actions targeting it. One side-effect of this change is that we'll produce Windows wheels for Python 3.9 by default. This is desirable. Differential Revision: https://phab.mercurial-scm.org/D9189
-
Gregory Szorc authored
It's been a while since we've ran `pip-compile -U`. Let's do that. When I ran this command, black was upgraded and newer versions of black complains about formatting differences. I didn't feel like shaving a yak, so I pinned the current black version to avoid churn. I manually ran tests against all major Python versions and I'm fairly certain no new test failures were introduced. Differential Revision: https://phab.mercurial-scm.org/D9188
-
Gregory Szorc authored
I ran `pip-compile -U` to update all packages to latest versions. I did this so the Windows environment is more modern. dulwich 0.20 dropped support for Python 2.7. Rather than add yet another requirements.txt file, I decided to just pin at an older release to minimize complexity. Differential Revision: https://phab.mercurial-scm.org/D9187
-
Gregory Szorc authored
We update the Windows and Linux environments to install CPython 3.9.0, which was released a few days ago. Differential Revision: https://phab.mercurial-scm.org/D9186
-
Gregory Szorc authored
We're only publishing Python 3.7+ wheels and other builds on Windows. Python 3.5 and 3.6 are not supported on this platform. Let's stop installing them in the development environment. Differential Revision: https://phab.mercurial-scm.org/D9185
-
- Oct 05, 2020
-
-
Gregory Szorc authored
While we've had code to produce Python 3 Windows installers with PyOxidizer, we haven't been advertising them on the web site due to a bug in making TLS connections and issues around resource handling. This commit upgrades our PyOxidizer install and configuration to use a recent Git commit of PyOxidizer. This new version of PyOxidizer contains a *ton* of changes, improvements, and bug fixes. Notably, Windows shared distributions now mostly "just work" and the TLS bug and random problems with Python extension modules in the standard library go away. And Python has been upgraded from 3.7 to 3.8.6. The price we pay for this upgrade is a ton of backwards incompatible changes to Starlark. I applied this commit (the overall series actually) on stable to produce Windows installers for Mercurial 5.5.2, which I published shortly before submitting this commit for review. In order to get the stable branch working, I decided to take a less aggressive approach to Python resource management. Previously, we were attempting to load all Python modules from memory and were performing some hacks to copy Mercurial's non-module resources into additional directories in Starlark. This commit implements a resource callback function in Starlark (a new feature since PyOxidizer 0.7) to dynamically assign standard library resources to in-memory loading and all other resources to filesystem loading. This means that Mercurial's files and all the other packages we ship in the Windows installers (e.g. certifi and pygments) are loaded from the filesystem instead of from memory. This avoids issues due to lack of __file__ and enables us to ship a working Python 3 installer on Windows. The end state of the install layout after this patch is not ideal for @: we still copy resource files like templates and help text to directories next to the hg.exe executable. There is code in @ to use importlib.resources to load these files and we could likely remove these copies once this lands on @. But for now, the install layout mimics what we've shipped for seemingly forever and is backwards compatible. It allows us to achieve the milestone of working Python 3 Windows installers and gets us a giant step closer to deleting Python 2. Differential Revision: https://phab.mercurial-scm.org/D9148
-
Gregory Szorc authored
- is not a valid identifier character in WiX Ids. So let's normalize accordingly. I discovered this issue after a subsequent change which introduces a directory with a - in its name. Differential Revision: https://phab.mercurial-scm.org/D9147
-
- Oct 03, 2020
-
-
Gregory Szorc authored
Let's use the latest/greatest version of Rust in the automation environment. Differential Revision: https://phab.mercurial-scm.org/D9146
-
- Oct 04, 2020
-
-
Gregory Szorc authored
Let's keep our build environment modern. We upgrade 3.5-3.8 on Linux. Just 3.7 and 3.8 on Windows because we don't use <3.7 on Windows. Differential Revision: https://phab.mercurial-scm.org/D9145
-
- Oct 05, 2020
-
-
Raphaël Gomès authored
I only found two such bugs in `contrib/perf.py` Differential Revision: https://phab.mercurial-scm.org/D9149
-
- Oct 01, 2020
-
-
Martin von Zweigbergk authored
`hg fix` runs the formatters from the repo root so it doesn't pick up the `rustfmt.toml` configs we had in each the `hg-core`, `hg-cpython`, and `rhg` packages, which resulted in warnings about `async fn` not existing in Rust 2015. This patch moves the `rustfmt.toml` file to the root so `hg fix` will use it. By putting the `rustfmt.toml` file in a higher-level directory, it also applies to the `chg` and `hgcli` packages. That makes `test-check-rust-format.t` fail, so this patch also applies the new formatting rules to those packages. Differential Revision: https://phab.mercurial-scm.org/D9142
-
- Sep 30, 2020
-
-
Raphaël Gomès authored
This feature gates (at compile-time) the use of the newly-added dirstate tree. The motivation for this is that the dirstate tree is currently *very* slow; replacing the current hashmap-based dirstate is not a viable solution in terms of performance... and why would you be using the Rust implementation if not for performance? The feature will also help reviewers better understand the differences that will slowly appear as the dirstate tree gets better. Differential Revision: https://phab.mercurial-scm.org/D9132
-
- Sep 03, 2020
-
-
Valentin Gatien-Baron authored
When a single version of hg is in use and it's in the PATH, using chg is just a matter of calling chg. But when there are multiple installations of hg+chg around, and hg is referred to with an absolute path, using chg is more annoying because it requires both changing the invocation to hg to use chg, but also setting CHGHG. Currently, we set HGPATH when we build chg to remove the need to set CHGHG in the previous paragraph. But that means chg now hardcodes its installation path, which makes the installation not relocatable. Hence this proposal to make chg find ./hg relative to itself (as opposed to CHGHG=./hg which find hg relative to cwd). This only works on linux as written, but since it's opt-in, it sounds fine. Tested by hand, as I'm not sure how else to test this. Differential Revision: https://phab.mercurial-scm.org/D9006
-
- Sep 18, 2020
-
-
Jun Wu authored
If stdio fds are missing (ex. fd 0 is not present), chg might open fds that take the numbers 0, and attachio would send the wrong fds to the client, which might cause unwanted behaviors. Avoid that by detecting the missing fds and falling back to the original hg. Differential Revision: https://phab.mercurial-scm.org/D9058
-
- Sep 02, 2020
-
-
haraldkl authored
When running Mercurial on Python 3 hgweb expects the config variable to be a bytestring. The solution proposed by Anton Shestakov is to use a byteprefix to the literal string defined cgi script as provided in this patch for hgweb.cgi, contrib/hgweb.fcgi and contrib/hgweb.wsgi. I am not sure whether this covers all relevant templates, but I couldn't find others. Differential Revision: https://phab.mercurial-scm.org/D8978
-
- Sep 01, 2020
-
-
Augie Fackler authored
This doesn't work if you have a PyOxidized hg on $PATH, but everything is fine if you just ignore that problem. Differential Revision: https://phab.mercurial-scm.org/D8975
-
- Jul 24, 2020
-
-
Kyle Lippincott authored
For most uses, this change is essentially a no-op, as this script is generally only run by test-check-py3-compat.t, which will already put `$TESTDIR/..` in `$PYTHONPATH`. When running outside of tests, however, `$PYTHONPATH` is likely not set, causing check-py3-compat.py to parse the file from the repo, but then import the installed version, and raise any errors about the installed version, not the one currently in the repo. Additionally, this helps users (like me) who have a strange set up where their home directory (and thus their hg repos) happen to be in a subdirectory of sys.prefix (which is /usr on my system). Since the '.' entry added to sys.path takes precedence over the absolute path of `$TESTDIR/..` in `$PYTHONPATH`, the path to the modules that it imports (and that show up in any stack trace) are *relative*, meaning that we don't detect them as starting with `sys.prefix`. Sample non-test invocation, and the difference this change makes (the path for 'error at <path>:<line>' is correct now):: Before: ``` $ python3 contrib/check-py3-compat.py mercurial/win*.py mercurial/win32.py: error importing: <ValueError> _type_ 'v' not supported (error at check-py3-compat.py:65) mercurial/windows.py: error importing: <ModuleNotFoundError> No module named 'msvcrt' (error at check-py3-compat.py:65) ``` After: ``` $ python3 contrib/check-py3-compat.py mercurial/win*.py mercurial/win32.py: error importing: <ValueError> _type_ 'v' not supported (error at win32.py:11) mercurial/windows.py: error importing: <ModuleNotFoundError> No module named 'msvcrt' (error at windows.py:12) ``` Differential Revision: https://phab.mercurial-scm.org/D8814
-
- Jul 06, 2020
-
-
Manuel Jacob authored
On Python 3, pycompat.{stdin,stdout,stderr} are usually block-buffered even if connected to a TTY. procutil.{stdin,stdout,stderr} provide consistent behavior across platforms and Python versions.
-
Antoine Cezar authored
Differential Revision: https://phab.mercurial-scm.org/D8682
-