- Feb 22, 2025
-
-
Pierre-Yves David authored
This is a follow up to e6069f84abbb. It turns about that there are multiple test condition that needs cleanup. This handle the usage of the first one.
-
- Feb 21, 2025
-
-
Mitchell Kember authored
I confirmed that this would have prevented the issue in !1280. For details see: https://rust-lang.github.io/rust-clippy/master/index.html#/or_fun_call
-
Mitchell Kember authored
This means that lints configured in rust/Cargo.toml will apply to all crates within the workspace. Currently there are none but I plan to add some.
-
Raphaël Gomès authored
Same as the previous patch, this is just dumb performance loss.
-
Raphaël Gomès authored
This is... really dumb and costs a ton of performance in a hot loop. It was 75% of a profile for a tip to null p1 node traversal in pure Rust. I'm at fault, done in 652149ed64f0. I thought clippy had a lint for this, but apparently not?
-
- Feb 20, 2025
-
-
Pierre-Yves David authored
This code is no longer used as the python packaging echo system evolved. This code was introduced in 10da5a1f25dd, with two feature in mind: - Mercurial may be installed into a non-standard location without having to set PYTHONPATH. - Multiple installations can use Mercurial from different locations. As a side effect it also provided performance improvement at a time where the `sys.path` could be greatly inflated from setuptools `.pth` files. And it also protected from incompatible directory within the `$PTYHONPATH` variable. Both of these benefit has faded overtime as `.pth` are less common and `$PYTHONPATH` is less used (as both where creating issue to more than just Mercurial). The initial motivation (easily install Mercurial anywhere), can now be handled by a new generation of tool like pipx or uv, so it is less of a concern. Regardless of all the above, the current code is no longer used. The evolution of python packaging means that installation always go through first building a location agnostic "wheel" that cannot update LIBDIR to a proper location. Upstream packaging (debian, redhat, etc…) does not seems to adjust this variable themself. So it is safer to drop this dead code that pretend we could be doing something with it.
-
Pierre-Yves David authored
This script seems a copy `./hg` with a few adjustment. However it does not seems to have been used in age given that is still use old API and package name that has not been around for a long while. So let's just delete it.
-
Matt Harbison authored
Windows can't typically invoke `*.py` directly as a command, and will instead show a prompt asking what program should be used to open the file. We can't directly invoke the interpreter as is usually done in this case, because the whole point is to run something not in `PATH`. The easiest thing to do is invoke a *.bat file that runs the interpreter. We can get away with this because the current implementation is to effectively run `cmd.exe /c %command%`, which doesn't need the file extension specified.
-
- Feb 19, 2025
-
-
Pierre-Yves David authored
Increasing the memory usage does not seems to yield much speed up, so we can restrict it more aggressively. However, unlimited memory usage can overwhelm a system and result in massive slowdown if the process start swapping. So it is still possible to configure it, but it is not longer used in any default profile. Having too many workers can slow things a bit, but not too much. So we can try to use higher default to yield benefit on large system.
-
- Jan 29, 2025
-
-
Pierre-Yves David authored
The overhead is not huge, but it still better to skip it.
-
- Feb 19, 2025
-
-
Pierre-Yves David authored
See inline document for details.
-
Matt Harbison authored
-
Matt Harbison authored
-
Matt Harbison authored
-
Matt Harbison authored
-
- Dec 18, 2024
-
-
Matt Harbison authored
I missed this in 6412dcec52d3 somehow. This is the same transformation as 3a90a6fd710d did for dirstate, but the CamelCase naming was already cleaned up here. See 4ef6dbc27a99 for the benefits of explicit subclassing.
-
Matt Harbison authored
We're still missing a few explicit bits of Protocol subclassing, and pytype found this when the subclassing is applied. So fix this first.
-
- Feb 19, 2025
-
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
- Feb 03, 2023
-
-
Pierre-Yves David authored
This is a generalisation of the new feature from evolve but for any diff, it allow to compares changes to patches regardless of the changes introduced by ancestors, this is typically useful after rebase and graft. I am not very happy about the name, but it is still experimental, so that can be improved later. Having the ability to compare ranges of commit would probably be handy too, but this changeset focus in getting the basic case in. We have to think about the UI a bit ahead however.
-
- Feb 18, 2025
-
-
Raphaël Gomès authored
This is the last one!
-
Raphaël Gomès authored
This is the last module left to migrate to PyO3 from rust-cpython. We will remove the rust-cpython code at the start of the next cycle.
-
Raphaël Gomès authored
This is the second to last module that is needed for a complete switchover from `rust-cpython`, the last being `copy_tracing`, which should follow soon.
-
Raphaël Gomès authored
This is a transliteration of the `update` module from `hg-cpython`.
-
Raphaël Gomès authored
This will host all repo-related operations. For now, this only contains the transliteration of the `repo_from_path` util from `hg-cpython`, but will later probably grow.
-
Raphaël Gomès authored
This is going to be useful for the upcoming `update` module, and is the transliteration of the util of the same name in `hg-cpython`. Explanations are inline.
-
Raphaël Gomès authored
This is going to be useful in more high-level modules like the upcoming `update` module.
-
Raphaël Gomès authored
PyO3 overrides the `__doc__` attributes to use the module's docstring.
-
Raphaël Gomès authored
-
- Feb 17, 2025
-
-
Raphaël Gomès authored
This was missed in 0bd91b0a1a93. It still works because we haven't removed the `hg-cpython` bridge yet. I'm honestly not sure if we should continue advertising for fsmonitor at all with the Rust extensions, but that's another discussion.
-
- Feb 18, 2025
-
-
Pierre-Yves David authored
The current choice is the default so nothing is changing there, but we document why we cannot use something else.
-
Pierre-Yves David authored
When we moved to use setuptools-scm in 30510238284e, we lost the version scheme that was engineers to make it safe to produce and consume nightly build from multiple branches (stable, default, and privates branches). This small change give use something close to what we have, but still don't support multiple branch.
-
- Feb 19, 2025
-
-
Pierre-Yves David authored
Windows need an additional flag to open the file properly.
-
- Feb 18, 2025
-
-
Pierre-Yves David authored
This argument have been around for a while and simplify the code. This is especially true as Windows does not have `os.fchmod` so we would have had to deal with this special case.
-
- Feb 07, 2025
-
-
Mitchell Kember authored
This adds support to rhg annotate for all the whitespace options: -w, --ignore-all-space -b, --ignore-space-change -B, --ignore-blank-lines -Z, --ignore-space-at-eol Note that --ignore-blank-lines has no effect on annotate so it is ignored. You can see this in dagop.py _annotepair which only checks if blocks are '=' or not, whereas the effect of --ignore-blank-lines is to change some '!' into '~'. When the other 3 are combined, we use the strongest option since -w implies -b and -b implies -Z. This is not explicit in the Python implementation, but I have verified that's how it behaves.
-
- Feb 12, 2025
-
-
Mitchell Kember authored
This was missing from the whitespace option testing in test-annotate.t. I changed the "a" file contents a bit to make the output different from the other whitespace flags.
-
- Feb 06, 2025
-
-
Arseniy Alekseyev authored
This one is much less likely to be problematic in practice since the data we're writing is constant-size, but it's not enough to completely rule out the problem.
-
- Feb 05, 2025
-
-
Arseniy Alekseyev authored
This commit makes the `sshpeer.doublepipe` object retry on short write, which fixes a deadlock in hg client-server communication, in particular when client needs to send a large message. Apparently Mercurial relies on `write` method on file objects to never return short writes, without checking, which leads to deadlocks. This work fine when the underlying file object is buffered, since buffered writers never return short writes. (why buffering has anything to do with this I don't know, but ok) It breaks horribly with raw IO, which happens to be used in sshpeer.
-