- Feb 19, 2025
-
-
Mitchell Kember authored
This makes revset::resolve_single return RevisionOrWdir. Previously, it returned RevlogError::WDirUnsupported (leading to abort, not fallback) for 2147483647 and ffffffffffffffffffffffffffffffffffffffff. It did not recognize 'wdir()' itself, so that would lead to Python fallback. Now, it treats all 3 cases the same: it returns RevisionOrWdir::wdir() and lets the caller decide what to do. I changed rhg cat, files, and annotate to return HgError::unsupported in this case, since wdir is valid. I made `rhg status --change wdir()` behave the same as `rhg status`, conforming to the test in test-status.t.
-
Mitchell Kember authored
This type represents either a checked Revision or the wdir() pseudo-revision (revision 0x7fffffff, node ffffffffffffffffffffffffffffffffffffffff). You construct it with revision.into() or Revision::wdir(), and destructure it with rev.exclude_wdir() which returns Option<Revision>. I considered something like `enum RevisionOrWdir { Wdir, Revision(Revision) }`, but decided on `struct RevisionOrWdir(BaseRevision)` for a few reasons: - It's more ergonomic for the ways it actually gets used, in my opinion. - It also avoids the possibility of an invalid value Revision(0x7fffffff). - It remains 4 bytes rather than 8. - It maintains the ordering: wdir is greater than all other revisions. I'm planning to use this for 'rhg annotate -r wdir()'.
-
- Feb 14, 2025
-
-
Mitchell Kember authored
This adds Config::username which returns HGUSER, ui.username, or EMAIL in that order, similar to ui.username() in Python. I considered following the pattern of EDITOR, VISUAL, PAGER, etc. and using add_for_environment_variable, but it's not possible to get the same precendence as in Python that way (in particular HGUSER coming after the repo .hg/hgrc), at least not without significant changes. This will be used for 'rhg annotate -r wdir() -u' to annotate the username on lines that were changed in the working directory.
-
- Mar 06, 2025
-
-
Pierre-Yves David authored
-
Pierre-Yves David authored
We could not easily run the CI on e705fec4a03f pre-publication, so of course, there are some output change with 7.0.
-
- Mar 05, 2025
-
-
Pierre-Yves David authored
Since 6.9.3 was made after 7.0rc0 we need to deal with more branching than usual.
-
Pierre-Yves David authored
-
Pierre-Yves David authored
-
Pierre-Yves David authored
When the manifest bundle constain some known requirement that does not affect the stream clone, we used to crash. However since we know them and know they don't affect the stream clone, we can ignore them. Mozilla generated such buggy manifest bundle for a time which allowed us to catch this error. The issue was not caught until 961900fbd67c (released in 6.9.2) as the requirements information were ignored for stream-v2 until then. We fix the issue, refactor the code for robustness and adds more tests to better catch this kind of issue in the future.
-
- Mar 01, 2025
-
-
Anton Shestakov authored
It was 80ec613fea43.
-
- Feb 28, 2025
-
-
Pierre-Yves David authored
Post rc0 merge.
-
Pierre-Yves David authored
This conclude the resolution of the merge issue in b7afc38468bd.
-
Pierre-Yves David authored
Now that the merge is fixed, we can merge this back into default.
-
Pierre-Yves David authored
The two "identical" merge create a "criss cross" situation. We resolve it as fast as possible.
-
Pierre-Yves David authored
For unclear reason, b7afc38468bd dropped all the change to "contrib/heptapod-ci.yml". This is the same merge as b7afc38468bd, but merging heptapod-ci.yml change from stable too.
-
Pierre-Yves David authored
-
Pierre-Yves David authored
-
Pierre-Yves David authored
-
- Feb 25, 2025
-
-
Pierre-Yves David authored
-
- Feb 26, 2025
-
-
Raphaël Gomès authored
This went unnoticed forever, I guess most users pass in `-r`.
-
Matt Harbison authored
The SourceForge packages were working as recently as late last week, and then yesterday I suddenly got a failure that the size of the download changed from what was expected. Let's not trust SourceForge for critical things (though the MinGW package manager likely uses that too; I'm not sure how to fix that). We probably don't need this at all, now that `install-windows-dependencies.ps1` installs `gettext` 0.22.5 since da74e81ef9af. But I don't feel like tinkering with the packaging code at this point, and running that PowerShell script in CI is probably pretty heavy handed.
-
- Feb 24, 2025
-
-
Mitchell Kember authored
I failed to notice before that bdiff_diff mutates its inputs by storing bookkeeping information in the `n` and `e` fields. This means &Lines can't be shared across threads, so Lines cannot be Sync. Fortunately nothing was using this. The parallel file reading and line splitting only relies on Send. The reason I didn't notice this to begin with was that Lines contains a *mut ffi::bdiffline, which is accessible from &Lines, so I never wrote or thought about &mut Lines. This pattern (using a mutable pointer stored in an immutable struct) would be expressed with RefCell if this was pure safe Rust.
-
- Feb 25, 2025
-
-
Mitchell Kember authored
We already use this in pyo3-sharedref. I need to use it in hg-core to assert that bdiff::Lines is !Sync.
-
- Feb 22, 2025
-
-
Matt Harbison authored
The comment heavily implies, and experimenting confirms, that there's no `sys.real_prefix` in a venv on Python3. I have no idea how the problems described would manifest, but nobody has complained for the several years of py3 releases build from a venv. The experimenting was done with 6.9.2 and the TortoiseHg build script.
-
- Feb 24, 2025
-
-
Matt Harbison authored
I noticed this when trying the Inno installer.
-
Matt Harbison authored
The file is now generated by `setuptools_scm`, which stores values as strings with strong quotes. This avoids the following failure at the end of the Inno installer build: <snip> creating installer Traceback (most recent call last): File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\packaging.py", line 70, in <module> run() File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\packaging.py", line 62, in run cli.main() File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\hgpackaging\cli.py", line 154, in main args.func(**kwargs) File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\hgpackaging\cli.py", line 35, in build_inno inno.build_with_pyoxidizer( File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\hgpackaging\inno.py", line 55, in build_with_pyoxidizer build_installer( File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\hgpackaging\inno.py", line 146, in build_installer version = read_version_py(source_dir) File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\hgpackaging\util.py", line 188, in read_version_py raise Exception('could not parse %s' % p) Exception: could not parse c:\Users\Matt\projects\mercurial\mercurial-devel\mercurial\__version__.py Note that non-tagged builds end up with complex version strings, and include characters that WiX rejects. That's probably fine- we don't do nightly or other non-tagged builds for installers. Also note that while the Inno installer is capable of using this version string as part of the installer, the WiX installer is not for some reason. That installer needs to be built with `--version VERSION` to inject the version into the installer metadata and the filename.
-
Matt Harbison authored
With `py -3.9 contrib/packaging/packaging.py wix --pyoxidizer-target x86_64-pc-windows-msvc`, there is an immediate failure after building the venv (3.9.13 has `setuptools` 58.1.0): ModuleNotFoundError: No module named 'setuptools.command.build' With that fixed, the same command then fails immediately with this error: Couldn't import setuptools_scm (direct call of setup.py?) Unfortunately, referencing `setuptools` in the requirements file needs `--allow-unsafe` to avoid a warning about not pinning `setuptools`. However, the same warning happens if `setuptools` is pinned to a specific revision, so I have no idea what it is complaining about. It's a separate venv that is only used for packaging, so we can fix it if it becomes a problem in the future. Interestingly, the Inno installer build doesn't fail immediately, and I can see it installing `setuptools` and `setuptools_scm` in the wall of text it emits. Eventually it does fail with the same errors without this change.
-
- Feb 22, 2025
-
-
Pierre-Yves David authored
Now that all user has been removed, we can safely drop them.
-
Pierre-Yves David authored
Same rational the parent changesets.
-
Pierre-Yves David authored
Same rational as the parent changeset.
-
Pierre-Yves David authored
Same rational as the parent changeset.
-
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.
-