Commits on Source (7)
-
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.
3fb2fbad4b13 -
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.
b624da86830e -
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.
33e06272ff1a -
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?
155e1e8dc055 -
Raphaël Gomès authored
Same as the previous patch, this is just dumb performance loss.
3fae90405966 -
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.
1ef08a0381a0 -
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
c4392e8bfb9f
Showing
- contrib/hgperf 0 additions, 112 deletionscontrib/hgperf
- hg 0 additions, 10 deletionshg
- rust/Cargo.toml 3 additions, 0 deletionsrust/Cargo.toml
- rust/hg-core/Cargo.toml 3 additions, 0 deletionsrust/hg-core/Cargo.toml
- rust/hg-core/src/revlog/index.rs 9 additions, 9 deletionsrust/hg-core/src/revlog/index.rs
- rust/hg-core/src/revlog/mod.rs 3 additions, 1 deletionrust/hg-core/src/revlog/mod.rs
- rust/hg-cpython/Cargo.toml 3 additions, 0 deletionsrust/hg-cpython/Cargo.toml
- rust/hg-pyo3/Cargo.toml 3 additions, 0 deletionsrust/hg-pyo3/Cargo.toml
- rust/pyo3-sharedref/Cargo.toml 3 additions, 0 deletionsrust/pyo3-sharedref/Cargo.toml
- rust/rhg/Cargo.toml 3 additions, 0 deletionsrust/rhg/Cargo.toml
- setup.py 0 additions, 74 deletionssetup.py
- tests/test-fix-path.t 10 additions, 1 deletiontests/test-fix-path.t
contrib/hgperf
deleted
100755 → 0