- May 03, 2021
-
-
Pierre-Yves David authored
A repository could use a mix of revlogv1 and revlogv2, making the requirements still necessary. Overall we should move away from the "requirements" file being used a way to configure the repository and stick to it "what do you need to access this repository". However this is a wider work for another time. In addition the logic we just dropped was confusing the `hg debugformat` command, breaking the upgrade code and inconsistent (eg: `sparse-revlog` is also implied by `revlogv2`). Finally, multiple other config option would imply the use of the `revlogv2` requirements, without drop the `generaldelta` one, leading to more inconsistency. Differential Revision: https://phab.mercurial-scm.org/D10612
-
Pierre-Yves David authored
It is oddly named and not used at all. The one used by the code is still `experimental.revlogv2`. So we drop that one option for consistency. We move associate documentation to the actual option. Differential Revision: https://phab.mercurial-scm.org/D10611
-
Pierre-Yves David authored
This will avoid "other" code to not overlook `_writing` usage. We introduces private method dedicated to writing to make use the right option are always used. Differential Revision: https://phab.mercurial-scm.org/D10610
-
Pierre-Yves David authored
Special cases aren't special enough to break the rules. Differential Revision: https://phab.mercurial-scm.org/D10609
-
Pierre-Yves David authored
The code doing actual writing is already doing the necessary seeking, so we could safely use 'r+'. This make the file objecs usable in more situation, like updating the sidedata information during pull. revlog: forcibly move the file cursor at the right location before writing This is a paranoid change in case the changelog computation moved the cursors under our feets. This is not known to happens right now. Differential Revision: https://phab.mercurial-scm.org/D10608
-
Pierre-Yves David authored
The `_writing` context need one, so we update the function signature before considering using `_writing` in rewrite_sidedata. Differential Revision: https://phab.mercurial-scm.org/D10607
-
Pierre-Yves David authored
Let's call the index file object and `ifh` and the data file object `dfh` as the rest of the revlog code. This will make future change clearer. Differential Revision: https://phab.mercurial-scm.org/D10606
-
Pierre-Yves David authored
Before this change, various revlog methods where managing the opening and closing of the revlog files manually and passing the file descriptor alors the call path. To simplify the tracking of the write operation by a future docket, we need something more organised. As a result, we introduce a `revlog._writing` context manager that will wrap each revlog update operation. The file descriptor are kept in the existing `revlog._writinghandles` parameter that was already used by the `addgroup` logic. All this change is internal to the revlog only, the "public" interface is not affected. The `addrevision` and `addgroup` logic are still responsible for setup up this context. However this new context give us multiple benefits: * all writer use a same, unified, logic, * this context is programmatically enforced, * each write "session" as a clearly identified start and end. The post-pull sidedata update logic is still doing writing by end and will be adjusted in a later changesets. This change affect the concurrency checker test, because register the state of the file in the transaction sooner in `addrevision` (about as early as what `addgroup` would do), so the abort is rollbacking the other commit. I don't want to weaken the current main logic. Differential Revision: https://phab.mercurial-scm.org/D10605
-
Pierre-Yves David authored
Indenting this beforehand will make a future changeset much simpler. Differential Revision: https://phab.mercurial-scm.org/D10604
-
Pierre-Yves David authored
Indenting this beforehand will make a future changeset much simpler. Differential Revision: https://phab.mercurial-scm.org/D10603
-
- May 06, 2021
-
-
Gregory Szorc authored
Newer versions of PyOxidizer use Python 3.9 by default. We previously pinned the version to 3.8 to facilitate porting to a new PyOxidizer version and diffing results. Now that the porting work is complete, let's bump Python to Python 3.9. This will effectively change our Windows Inno and WiX Python 3 installers from Python 3.8 to 3.9. .. bc:: Windows .msi and .exe installers now use Python 3.9 instead of Python 3.8. Differential Revision: https://phab.mercurial-scm.org/D10689
-
Gregory Szorc authored
We recently taught our in-tree PyOxidizer configuration file to produce MSI installers with WiX using PyOxidizer's built-in support for doing so. This commit changes our WiX + PyOxidizer installer generation code to use this functionality. After this change, all the Python packaging code is doing is the following: * Building HTML documentation * Making gettext available to the build process. * Munging CLI arguments to variables for the `pyoxidizer` execution. * Invoking `pyoxidizer build`. * Copying the produced `.msi` to the `dist/` directory. Applying this stack on stable and rebuilding the 5.8 MSI installer produced the following differences from the official 5.8 installer: * .exe and .pyd files aren't byte identical (this is expected). * Various .dist-info/ directories have different names due to older versions of PyOxidizer being buggy and not properly normalizing package names. (The new behavior is correct.) * Various *.dist-info/RECORD files are different due to content divergence of files (this is expected). * The python38.dll differs due to newer PyOxidizer shipping a newer version of Python 3.8. * We now ship python3.dll because PyOxidizer now includes this file by default. * The vcruntime140.dll differs because newer PyOxidizer installs a newer version. We also now ship a vcruntime140_1.dll because newer versions of the redistributable ship 2 files now. The WiX GUIDs and IDs of installed files have likely changed as a result of PyOxidizer's different mechanism for generating those identifiers. This means that an upgrade install of the MSI will replace files instead of doing an incremental update. This is likely harmless and we've incurred this kind of breakage before. As far as I can tell, the new PyOxidizer-built MSI is functionally equivalent to the old method. Once we drop support for Python 2.7 MSI installers, we can delete the WiX code from the repository. This commit temporarily drops support for extra `.wxs` files. We raise an exception instead of silently not using them, which I think is appropriate. We should be able to add support back in by injecting state into pyoxidizer.bzl via `--var`. I just didn't want to expend cognitive load to think about the solution as part of this series. Differential Revision: https://phab.mercurial-scm.org/D10688
-
Gregory Szorc authored
I'll be refactoring how the WiX installer creation calls into pyoxidizer and will need a lower level function for facilitating that. The new `run_pyoxidizer()` builds our execution environment (with gettext available) and invokes `pyoxidizer`. Differential Revision: https://phab.mercurial-scm.org/D10687
-
Gregory Szorc authored
I'm going to split this function up in a future commit and I'll want the name "run_pyoxidizer()" for a lower-level function for invoking `pyoxidizer`. Differential Revision: https://phab.mercurial-scm.org/D10686
-
Gregory Szorc authored
This is part of some light refactoring to enable us to use PyOxidizer for WiX MSI installer generation. Differential Revision: https://phab.mercurial-scm.org/D10685
-
Gregory Szorc authored
Newer versions of PyOxidizer feature built-in support for code signing. You simply declare a code signer in the Starlark configuration file, activate it for automatic signing, and PyOxidizer will add code signatures to signable files as it encounters them. This commit teaches our Starlark configuration file to enable automatic code signing. But only on Windows for the moment, as our immediate goal is to overhaul the Windows packaging. The feature is opt-in: you must pass variables to PyOxidizer's build context via `pyoxidizer build --var` or `pyoxidizer build --var-env` to activate code signing. Differential Revision: https://phab.mercurial-scm.org/D10684
-
Gregory Szorc authored
Newer versions of PyOxidizer have support for building WiX MSI installers "natively." Essentially, you can script the definition of your WiX installer via Starlark and PyOxidizer can invoke WiX tools to produce the installer. This commit teaches our PyOxidizer config file to produce MSI installers similarly to how `contrib/packaging/packging.py wix` would do it. We had to make a very minor change to `mercurial.wxs` to reflect different paths depending on who builds. This is because when PyOxidizer builds WiX installers, it does so from an isolated directory, not Mercurial's source directory. We simply copy the files into the build environment so they are accessible. After this change, running `pyoxidizer build msi` produces a nearly identical install layout to what the previous method produces. When I applied this series on top of the 5.8 tag, here is the list of differences and explanations: * docs/*.html files are missing from the new installer because the Python build environment doesn't have docutils. * .pyd and .exe files differ, likely because I'm using a different Visual Studio toolchain on my local computer than the official build environment. * Various .dist-info/ directories have different names. This is because older versions of PyOxidizer had buggy behavior and weren't properly normalizing package names in .dist-info/ directories. e.g. we went from `cached-property-1.5.2.dist-info` to `cached_property-1.5.2.dist-info`. * Translations (.mo files) may be missing if gettext isn't in %Path%. This is because the packaging.py code installs gettext and ensures it can be found. * Some *.dist-info/RECORD files vary due to SHA-256 content digest divergence due to build environment differences. (This should be harmless.) * The new install layout ships a python3.dll because newer versions of PyOxidizer ship this file. * The new install layout has a different vcruntime140.dll and also a vcruntime140_1.dll because newer versions of PyOxidizer ship a newer version of the Visual C++ Redistributable Runtime. The new PyOxidizer functionality is not yet integrated with packaging.py. This will come in a subsequent commit. So for now, the new functionality introduced here is unused. Differential Revision: https://phab.mercurial-scm.org/D10683
-
Gregory Szorc authored
The name of this attribute changed in PyOxidizer 0.11. Differential Revision: https://phab.mercurial-scm.org/D10682
-
Gregory Szorc authored
The split targets existed to enable the use of a non-default distribution flavor on Windows. Modern versions of PyOxidizer use the "standalone_dynamic" distribution flavor by default. So our split brain workaround is no longer needed. Here, we unify the targets. We also remove an unreferenced target function to create a resources file. Differential Revision: https://phab.mercurial-scm.org/D10681
-
Gregory Szorc authored
PyOxidizer now provides MSI installers and pre-built Linux binaries. So we install that way. This significantly reduces the time to bootstrap a new machine in automation, as building PyOxidizer from source on a low core count machine takes several minutes. This change temporarily breaks the ability of the automated environment to use the in-repo pyoxidizer.bzl configuration file, as there are backwards-incompatible changes with the upgrade that need to be reflected. We'll handle those in subsequent commits. Differential Revision: https://phab.mercurial-scm.org/D10680
-
Gregory Szorc authored
Newer versions of PyOxidizer use version 3.9 by default. As part of upgrading PyOxidizer, we want to pin the version at 3.8 so we can compare differences more easily. Differential Revision: https://phab.mercurial-scm.org/D10679
-
Gregory Szorc authored
This isn't used for anything and can safely be removed. Differential Revision: https://phab.mercurial-scm.org/D10678
-
Gregory Szorc authored
I'm not sure why we don't install the minimum required Rust version here like we do for Linux. Whatever: that's unrelated to wanting to stay modern. Differential Revision: https://phab.mercurial-scm.org/D10677
-
Gregory Szorc authored
Let's keep our Python versions modern. Differential Revision: https://phab.mercurial-scm.org/D10676
-
Gregory Szorc authored
Our minimum supported Rust is 1.41.1 per rust/README.rst. We also bump the modern Rust version to latest stable to stay current. Differential Revision: https://phab.mercurial-scm.org/D10675
-
Gregory Szorc authored
Let's keep our Linux environment up to date. Differential Revision: https://phab.mercurial-scm.org/D10674
-
- May 07, 2021
-
-
Gregory Szorc authored
The automation environment is refusing to build with the previous file because some dependencies won't install on Python 3.5. I couldn't find an easy way to salvage the situation with a single requirements.txt file. So, I decided to introduce a variant for Python 3.5. As part of this, we update packages to latest versions. (I do question why we are still supporting Python 3.5...) Differential Revision: https://phab.mercurial-scm.org/D10690
-
- May 15, 2021
-
-
Karthikeyan Singaravelan authored
Differential Revision: https://phab.mercurial-scm.org/D10711
-
- May 10, 2021
-
-
Simon Sapin authored
This is actually necessary to make `DirstateMap::has_dir` correct, since it assumes that a node without a `DirstateEntry` has at least one descedant node with a `DirstateEntry`. This bug would become apparent when a later changeset persists tree nodes on disk in the "dirstate-v2" format. Differential Revision: https://phab.mercurial-scm.org/D10706
-
Simon Sapin authored
It should behave the same as before. This will enable the next changeset to run code on the way "down" (in order to removing newly-empty nodes). Differential Revision: https://phab.mercurial-scm.org/D10705
-
- May 11, 2021
-
-
Martin von Zweigbergk authored
I don't understand why, but putting `revset('parents()') % {desc}` in the commit message template for amend resulted in a crash because `memctx.hex()` did `hex(self.node())` and its node was None. This patch fixes that. Martin von Zweigbergk <martinvonz@google.com> Differential Revision: https://phab.mercurial-scm.org/D10707
-
- Apr 15, 2021
-
-
Pierre-Yves David authored
The next changeset introduce one. Differential Revision: https://phab.mercurial-scm.org/D10450
-
Pierre-Yves David authored
We move the function in a lower level module to avoid cycle. It moves next to `parsebool` who had to migrate for the same reasons. Differential Revision: https://phab.mercurial-scm.org/D10449
-
- Apr 16, 2021
-
-
Pierre-Yves David authored
The content of the `[paths]` config section is receiving transformation that make it hard to recognise whats the actual name, and the next changeset will make it worse. So we use the official API for this instead. Differential Revision: https://phab.mercurial-scm.org/D10448
-
- Apr 15, 2021
-
-
Pierre-Yves David authored
We move from a `{name → path}` mapping to a `{name → [path]}` mapping. And update all user code accordingly. For now, all the list contains exactly one element, but we are now in a good place to make the config understand a list of url. Differential Revision: https://phab.mercurial-scm.org/D10447
-
Pierre-Yves David authored
This will no longer modify `path` inplace so it does not make much sense as a method. Differential Revision: https://phab.mercurial-scm.org/D10446
-
Pierre-Yves David authored
This will be useful when inheriting from multiple path at the same time. Differential Revision: https://phab.mercurial-scm.org/D10445
-
Pierre-Yves David authored
This make it possible to display multiple path per name in the near future. Differential Revision: https://phab.mercurial-scm.org/D10444
-
- May 11, 2021
-
-
Simon Sapin authored
Trying to improve coverage for various non-ovbious scenarios Differential Revision: https://phab.mercurial-scm.org/D10704
-
- May 08, 2021
-
-
Matt Harbison authored
The latest py3 is used if the minor number isn't specified. After running the script to install all of the build dependencies, that moved the default from 3.8 to 3.9 on the CI system. That in turn caused a bunch of tests to be skipped that were running prior, even when the test runner was invoked with `py -3.8`. While we should almost always use the latest version, we really shouldn't make it hard to test different versions or allow things to randomly break in subtle ways like that. Differential Revision: https://phab.mercurial-scm.org/D10702
-