- Mar 17, 2025
-
-
Pierre-Yves David authored
A few notable bugfix landed.
-
- Mar 14, 2025
-
-
Arseniy Alekseyev authored
It waits for two NULL terminators: a bundle part terminator followed by a bundle terminator. Since the empty bundle has no parts, bundle part terminator never comes. The fix is to only start waiting for a bundle part terminator once we've seen a part.
-
- Mar 12, 2025
-
-
Pierre-Yves David authored
Updating the doc was overlooked in e75ed9ae5fb9.
-
Pierre-Yves David authored
Some operation and state are still around after the destination bundle are created. So we have to wait on another conditional too.
-
- Mar 06, 2025
-
-
Arseniy Alekseyev authored
-
- Mar 11, 2025
-
-
Pierre-Yves David authored
This was breaking automatic clone bundle generation. This changeset fixes it and add a test to catch it in the future.
-
Pierre-Yves David authored
In 5b8f6e198a6e, we wrongly called `vfs._auditpath` on the pre-encoding path, so we would get abort on problem that the encoding is here to handle. So we fix the problem (easily) and update the test to cover this (with significantly more work). Thanks to Matt Harbison for spotting this during the freeze.
-
Pierre-Yves David authored
In order to test some stream clone related feature, we need to be able to create file with more complex name and delete them. We document the file related feature in the process.
-
Pierre-Yves David authored
This will be useful to test deletion in the next changesets.
-
Pierre-Yves David authored
The feature was not documented, so we start with documenting it before extending it.
-
- Mar 10, 2025
-
-
Pierre-Yves David authored
When we run the job multiple time, the upload step fails because the file always exists. So we pass the `--skip-existing` flag that is supposed to help with that… when supported. This might have no effect outside of upload to PyPI as the doc says: Continue uploading files if one already exists. (Only valid when uploading to PyPI. Other implementations may not support this.)
-
- Feb 28, 2025
-
-
Anton Shestakov authored
Let's repeat 42baf12efd21.
-
- Mar 06, 2025
-
-
Pierre-Yves David authored
When the command where run in the background, the std was closed. So we have to so do some file description juggling to make sure it is passed down. This was affecting automatic clone bundle generation and associated test was added.
-
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
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.
-