- Nov 24, 2020
-
-
Simon Sapin authored
No functional change, checking comes later. Differential Revision: https://phab.mercurial-scm.org/D9398
-
Simon Sapin authored
For now it only prints the contents of `.hg/requires` as-is, without parsing. Differential Revision: https://phab.mercurial-scm.org/D9397
-
- Nov 19, 2020
-
-
Augie Fackler authored
Differential Revision: https://phab.mercurial-scm.org/D9342
-
- Nov 16, 2020
-
-
Raphaël Gomès authored
In the rare cases when either the OS/filesystem throws an error on an otherwise valid action, or because a path is not representable on the filesystem, or because of concurrent actions in the filesystem, we want to warn the user about said path instead of bubbling up the error, causing an exception to be raised in the Python layer. Differential Revision: https://phab.mercurial-scm.org/D9320
-
Raphaël Gomès authored
This is probably never going to be called after the next few patches, but we might as well make sure this is done correctly for the future rewrite. Differential Revision: https://phab.mercurial-scm.org/D9319
-
- Nov 10, 2020
-
-
Augie Fackler authored
Differential Revision: https://phab.mercurial-scm.org/D9290
-
- Nov 03, 2020
-
-
Augie Fackler authored
Windows has some extra constraints that require a multi-file install, but we expect folks to use an MSI or similar installer there so it's less of a big deal. Differential Revision: https://phab.mercurial-scm.org/D9289
-
- Oct 20, 2020
-
-
Antoine cezar authored
Unlike other later implemented commands `debugdata` only supported revision number. This changeset add full node id support for consistency with other commands. Differential Revision: https://phab.mercurial-scm.org/D9230
-
- Sep 28, 2020
-
-
Antoine cezar authored
1. Hash encoded path are in `.hg/store/dh` instead of `.hg/store/data`. 2. Path encoded index and data files may not have the same parent path. It is not just about replacing `.i` by `.d` Differential Revision: https://phab.mercurial-scm.org/D9121
-
- Oct 29, 2020
-
-
Antoine cezar authored
Differential Revision: https://phab.mercurial-scm.org/D9264
-
- Oct 09, 2020
-
-
Pierre-Yves David authored
But explicitly with the special case early, laying out the various case become simpler. (The initial motivation was to make some future lifetime error simpler). Differential Revision: https://phab.mercurial-scm.org/D9203
-
- Oct 22, 2020
-
-
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
-
-
Pierre-Yves David authored
This will help readability a bit and make the next change simpler to read. Differential Revision: https://phab.mercurial-scm.org/D9202
-
- Oct 08, 2020
-
-
Pierre-Yves David authored
They seems to have sneaked there somehow. Differential Revision: https://phab.mercurial-scm.org/D9201
-
- 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
-
- Oct 01, 2020
-
-
Raphaël Gomès authored
This is not done for the `dirstate-tree` feature, since it lacks `iter_mut`. Differential Revision: https://phab.mercurial-scm.org/D9136
-
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
-
Raphaël Gomès authored
Differential Revision: https://phab.mercurial-scm.org/D9137
-
- Sep 28, 2020
-
-
Raphaël Gomès authored
Debian stable backported `rustc 1.41.1` for a Firefox release that needed it, so we can finally update the compiler version to something that isn't more than a year old. This means that (among other things [1]), `async await` syntax is usable! Differential Revision: https://phab.mercurial-scm.org/D9138
-
- Sep 30, 2020
-
-
Raphaël Gomès authored
The previous patch added the `dirstate-tree` feature gate to enable the two dirstate implementations to co-habit while the tree-based one gets better. This patch copies over the code that differs, be it because the algorithm changed or because the borrowing rules are different. Indeed, `DirstateTree` is not observationally equivalent to the std `HashMap` in the APIs we use: it does not have the `Entry` API (yet?) and its iterator returns owned values instead of references. This last point is because the implementation needs to be changed to a more clever and efficient solution. Differential Revision: https://phab.mercurial-scm.org/D9133
-
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
-
Raphaël Gomès authored
Maybe there is a small divergence in the nightly formatter? This didn't seem to trip the CI. Differential Revision: https://phab.mercurial-scm.org/D9131
-
- Sep 23, 2020
-
-
Raphaël Gomès authored
Before this patch, it is not possible to create a `Matcher` trait-object (like `Box<dyn Matcher>`), because of the use of a generic parameters in some methods, namely `impl AsRef<HgPath>`. While this makes the interface less flexible for callers in theory, it does not change anything in the current codebase. Until something like [1] is implemented, this is a "tradeoff" that we need to make anyway. [1] https://internals.rust-lang.org/t/pre-rfc-expand-object-safety/12693 Differential Revision: https://phab.mercurial-scm.org/D9071
-
- Sep 28, 2020
-
-
Raphaël Gomès authored
This removes some justified warnings and one hard error that, while technically not a bug, was an ugly oversight on my part. Differential Revision: https://phab.mercurial-scm.org/D9094
-
Antoine cezar authored
Differential Revision: https://phab.mercurial-scm.org/D9109
-
Antoine cezar authored
Differential Revision: https://phab.mercurial-scm.org/D9108
-
Antoine cezar authored
(D8958#inline-14994 followup 2/2) [X] make `Index` owner of its bytes [X] make `Index::new` return an error if `offset != bytes.len()` Differential Revision: https://phab.mercurial-scm.org/D9107
-
Antoine cezar authored
Prevent building `Index` every time it is needed. It was a bad idea anyway. When `Index::new` will return `Result` it will avoid things like `Revlog::len` returning `Result<usize>` instead of `usize`. [X] make `Index` owner of its bytes [ ] make `Index::new` return an error if `offset != bytes.len()` Differential Revision: https://phab.mercurial-scm.org/D9106
-
Antoine cezar authored
Differential Revision: https://phab.mercurial-scm.org/D9105
-
Antoine cezar authored
Differential Revision: https://phab.mercurial-scm.org/D9104
-
Antoine cezar authored
Differential Revision: https://phab.mercurial-scm.org/D9103
-
Antoine cezar authored
Differential Revision: https://phab.mercurial-scm.org/D9102
-
Antoine cezar authored
Differential Revision: https://phab.mercurial-scm.org/D9101
-
Antoine cezar authored
Differential Revision: https://phab.mercurial-scm.org/D9100
-
Antoine cezar authored
Differential Revision: https://phab.mercurial-scm.org/D9099
-
Antoine cezar authored
Differential Revision: https://phab.mercurial-scm.org/D9097
-
Antoine cezar authored
Differential Revision: https://phab.mercurial-scm.org/D9096
-
Antoine cezar authored
(D8958#inline-14992 followup) Differential Revision: https://phab.mercurial-scm.org/D9095
-
Antoine cezar authored
Differential Revision: https://phab.mercurial-scm.org/D9083
-