- Feb 18, 2025
-
-
Pierre-Yves David authored
The code was calling `_set_identity` in too many places, resulting in fetching cache information after reading the on disk data. This could result in old data labelled with the identity of new, never loaded data. Fixing it solve the issue spotted in the previous changesets. Further cleanup are warranted but it seems more reasonable to do them on stable.
-
Pierre-Yves David authored
This was giving the wrong output in the `dirstate-v2-rewrite` case. As the dirstate is rewritten, the data file is missing and we reload the full dirstate. The make the dirstate reloaded after the commit and it no longer see the file as dirty. Note that if we were deleting the data file less aggressively, we would see the other output. (for example if we were keeping old data file around for some time before deletion). One last thing… fixing this reveal a quite serious bug where a `hg status` end up overwriting a `hg update` done concurrently. Hooray for proper testing.
-
Pierre-Yves David authored
`#if dirstate-v2` is always false, because `dirstate-v2` is not one of the test cases. So we fix the conditionnal and adjust the expected matching. This highlight that the rhg/no-rhg output differ because an issue in the code. We will fix that in the next changeset.
-
Pierre-Yves David authored
We are going to fix a bug in the test framework, that will reveal a fairly serious bug with the Rust code. So we update the test before hand for clarity.
-
Julien Cristau authored
stream bundle specs specify requirements, but we were ignoring this when selecting which bundle to apply, causing spurious clone failures.
-
- Feb 12, 2025
-
-
Matt Harbison authored
I guess pytype 2023.11.21 goes out to lunch on this module- 2024.10.11 found this, and PyCharm sees the problem too. This broke back in a43d256c041a when the internal attr was made a property.
-
- Feb 08, 2025
-
-
Matt Harbison authored
This backs out 7b837fabc990 and eda075d7b2ac. The cleanup to transition away from bytes broke JavaHg, which is used by hosting software SCM Manager. I'm not sure who maintains JavaHg these days, so I'm not sure how to get a build out and get everyone to upgrade. Let's revert the change for a quicker fix (and fix an unknown number of other unmaintained extensions), and rely on pytype to flag any potential issues. It's also trivial, so let's not wait until the next feature release (with the added burden for packagers this cycle in dealing with the `setup.py` changes).
-
- Jan 29, 2025
-
-
Arseniy Alekseyev authored
Apparently we "return" instead of doing "continue", which seems clearly unintentional. I split the function in two to make this particular bug impossible.
-
- Jan 28, 2025
-
-
Arseniy Alekseyev authored
Do the same whitespace-at-the-edge validation in rhg that we do in Python.
-
- Jan 10, 2025
-
-
Arseniy Alekseyev authored
While we're at it, forbid empty path components (aka repeated slashes) as well because they can cause problems (at the very least a crash failing HgPath validation in rust code path).
-
Arseniy Alekseyev authored
Forbid whitespace at the edges of the pattern because it just doesn't work correctly.
-
- Jan 16, 2025
-
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
- Jan 14, 2025
-
-
Mitchell Kember authored
This makes hg-core use ResourceProfileValue::Medium as the default. Before, it used ResourceProfileValue::Default (now removed), which was not supposed to be a real value, but rather an indirection meaning to use the default (medium). The motivation for this is that my implementation of rhg annotate was slower on some files than Python. This was because Python used the "Medium" profile by default (enabling the revlog chunk cache), while Rust used the "Default" profile (disabling the revlog chunk cache).
-
Mitchell Kember authored
This makes hg-core read resource profile configs from usage.resources. Before, it correctly used that for sub-values such as usage.resources.memory, but for the generic value it incorrectly used usage.resource (singular).
-
Mitchell Kember authored
This makes get_resource_profile less confusing. Before, RESOURCE_DEFAULT was a special indirect value which meant to use DEFAULT_RESOURCE. I removed it while preserving the same behavior. The motivation for this is that the Rust implementation gets the default logic wrong due to confusion about defaults. I will fix it in a follow-up commit.
-
- Jan 15, 2025
-
-
Pierre-Yves David authored
So that we can build official package from the CI.
-
- Jan 02, 2025
-
-
Matt Harbison authored
COPYING.rtf has a few additional changes (like the website URL), because it's been unmaintained for awhile now.
-
- Dec 18, 2024
-
-
Pierre Augier authored
The use of `--no-use-pep517` leads to ERROR: Disabling PEP 517 processing is invalid: project specifies a build backend of setuptools.build_meta in pyproject.toml
-
- Dec 13, 2024
-
-
Pierre-Yves David authored
The point of these nightly build is to catch error on case we do not systematically test. So we better test them.
-
Pierre-Yves David authored
Otherwise the scheduled build are useless.
-
- Dec 05, 2024
-
-
Taylor R Campbell authored
Text that is meant to represent zero-width output in a readline prompt, such as terminal escape sequences, is supposed to be delimited by \001 ... \002: > Applications may indicate that the prompt contains characters that > take up no physical screen space when displayed by bracketing a > sequence of such characters with the special markers > RL_PROMPT_START_IGNORE and RL_PROMPT_END_IGNORE (declared in > readline.h `\001' and `\002', respectively). This may be used to > embed terminal-specific escape sequences in prompts. https://tiswww.cwru.edu/php/chet/readline/readline.html#index-rl_005fexpand_005fprompt When formatting a readline prompt in ui._readline, arrange to do this in the color.py labelling routines. Keeping mutable dynamically scoped state like this isn't great but threading it as a parameter through all the subroutines seems like much more trouble. (This doesn't address the missing line break -- that's a separate bug in libedit.) https://bz.mercurial-scm.org/show_bug.cgi?id=6930
-
Taylor R Campbell authored
Add missing line break so the heading is treated as such, not as paragraph text. https://bz.mercurial-scm.org/show_bug.cgi?id=6942
-
- Dec 06, 2024
-
-
Matt Harbison authored
A recent series got landed with a pytype failure, because it wasn't propagated to the CI caller (see c47fe7fd312d). I suspect it started recently with 069735062524, because failures have been flagged in the past. The shebang line needs to be specific to bash, otherwise it ignores this non-POSIX extension. I'm not aware of a POSIX flavor of this option.
-
- Nov 25, 2024
-
-
Matt Harbison authored
Since Python 2.7 and 3.5, `typing.ByteString` was defined as an alias for `bytes | bytearray | memoryview`, and `bytes` was also accepted as a shorthand for this, so we have `bytes` sprinkled all over the codebase. But then PEP-688 reversed all of that by deprecating `typing.ByteString` and its successor `collections.abc.ByteString` in Python 3.12 (as well as the `bytes` shorthand)[1], and removing it completely in Python 3.14. That leaves us with a couple of problems, namely defining something useful that spans py3.8-py3.13 and keeps pytype happy, and finding all of the instances where `bytes` doesn't really mean `bytes`. The current successor to all of this is `collections.abc.Buffer` in Python 3.12 (or `typing_extensions.Buffer` in previous versions). However, the current CI does type checking using Python 3.11 (so the former is not avaiable), and pytype has issues with importing `typing_extensions.Buffer`[2]. The good news is we don't need to deal with this mess immediately, since the type annotation evaluation is delayed to the type checking phase, and we're making no effort at supporting it in all supported versions of Python. So by delaying the import of this particular symbol, we can still use it for type checking purposes, but can start assessing Python 3.14 problems without doing a lot of extra work. Putting this on stable will allow people interested in 3.14 to work on it 4-5 extra months earlier (and apparently there's some interest). [1] https://peps.python.org/pep-0688/#no-special-meaning-for-bytes [2] https://github.com/google/pytype/issues/1772
-
- Nov 27, 2024
-
-
Matt Harbison authored
It seems like this command doesn't currently cause the wheels to be cached, but since I already had to prevent `pip` from caching when building wheels in 1a09563a615c, and also disable it in a test in 30b5dc517ec2, let's just be explicit that we don't want caching, in case the default behavior changes.
-
Matt Harbison authored
After 1a09563a615c, there's one more wheel that gets cached in the user's pip cache in the macOS CI runner. The wheel corresponds to the version being used for the tests, but it doesn't get cached until the 3rd or 4th test shard is run, so it's not an issue with installing to run the tests. This seems to eliminate that. This doesn't seem to be an issue on Windows or Linux in my setup. Windows not being affected is likely because we set `$USERPROFILE` to redirect the home directory to `$TESTTMP` when running tests, since 08fd76a553c9. (When checking with `"$PYTHON" -m pip cache dir`, it points to `$TESTTMP/pip/cache`.) We do also set `$HOME` to this same location when running posix tests, but I can't tell what's going on locally in Linux, because running `pip` directly in the *.t explodes, and `"$PYTHON" -m pip --version` prints `pip 9.0.1 from /usr/lib/python3/dist-packages`, so that's likely before caching was enabled[1]. Running `python3.8 -m pip --version` locally outside of the *.t (the same version used to invoke the test runner), prints `pip 24.2 from /home/mharbison/.local/lib/python3.8/site-packages/pip (python 3.8)`. In CI, both macOS and Linux print a modern version of `pip`, and list the cache as being under `$TESTTMP`, but then it doesn't end up there on macOS. No idea if it is a pip bug, or what. But let's be explict and disable caching. [1] https://github.com/pypa/pip/blob/fe0925b3c00bf8956a0d33408df692ac364217d4/docs/html/topics/caching.md?plain=1#L37
-
Matt Harbison authored
I had a pile of these one-shot wheels cached on the mac, taking about 1.2G of space from the few weeks we've been building wheels to test, and with the few times the macOS tests were actually run. There's not much point in caching these, since the tests run from a wheel file the tests are force fed. There is still an issue with one wheel from the tests being cached (probably on install), but that's 1/6 of the original problem. I'm putting this in the `pyproject.toml` because I think that's where we should have all of the `cibuildwheel` config collected. There's a concurrent effort to modernize `setup.py` and use this file more, so I'll hold off on pushing most of the config in here for now. But this applies the setting to all OSes, as well as when run through either CI or the individual buid scripts, so I think this is clearly the right way to go. Note that the docs for `cibuildwheel` talks about the intention to move from `pip` to `build` some day. This config only covers the former, so the other config example[1] with the latter may be needed at some point. But I don't see an obvious option for that tool, so we'll cross that bridge when we come to it. [1] https://cibuildwheel.pypa.io/en/v2.22.0/options/#examples_6
-
- Nov 20, 2024
-
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
Raphaël Gomès authored
I've folded bugfixes that only exist to fix 6.9-specific things to the best of my attention span for this task.
-
Pierre-Yves David authored
I hope this is not too scary, but as discussed last month, we need to have a better compatibility story before pushing more people toward Rust.
-
Pierre-Yves David authored
As discussed last Friday after publishing the rc wheel, we need to update the rust readme and highlight that change in the release announcement if we want people using Rust to keep being able to use pip.
-
Pierre-Yves David authored
Sight.
-
- Nov 13, 2024
-
-
Pierre-Yves David authored
We don't test them yet, but we build them, as as many other flavors.
-
- Nov 16, 2024
-
-
Matt Harbison authored
This is mostly a translation of `contrib/packaging/build-windows-wheels.bat`, except the default pythons to build can be inferred from `setup.py` and/or `pyproject.toml`, and all use the same configuration. All we need to do is force the building of translation files, tell it to skip pypy wheels, and tell it to build universal2 wheels instead of for the current architecture.
-
- Nov 18, 2024
-
-
Raphaël Gomès authored
Possibly we would have caught the looming bug earlier if this had been named closer to what it actual is used for.
-
Raphaël Gomès authored
This is not currently a problem since the options are the same, but would have become one at some point in the future.
-
- Nov 15, 2024
-
-
Pierre-Yves David authored
The embarrassing details of how this was discovered will be kept under silence.
-