issue6528: implement _is_revision_affected_fast using callback
The delta comming from a bundle/stream does not exists in the revlog yet, so we
will need other way to retrieve the same information.
To prepare for this we split the function to use callbacks in the core logic.
Differential Revision: https://phab.mercurial-scm.org/D11268
issue6528: implement _is_revision_affected using callback
The delta comming from a bundle/stream does not exists in the revlog yet, so we
will need other way to retrieve the same information.
To prepare for this we split the function to use callbacks in the core logic.
Differential Revision: https://phab.mercurial-scm.org/D11267
debugcommands: add a `--paranoid` option to `debug-repair-issue-6528`
See justification inline.
Differential Revision: https://phab.mercurial-scm.org/D11263
repair: improve performance of detection of revisions affected by
issue6528
Explanations inside the patch. I've tested this on Mozilla-Central and it's
5 times faster than the naive approach on my laptop.
Differential Revision: https://phab.mercurial-scm.org/D11262
debugcommands: introduce a debug command to repair repos affected by
issue6528
This command is quite basic and slow, it will loop over the entirety of the
filelogs in the repository and check each revision for corruption, then fixes
the affected filelogs. It takes under 25 minutes for Mozilla-Central on my
not-top-of-the-line laptop, using the `--to-report` and `--from-report` options
will make this pretty tolerable to use, I think.
This change also introduces a test for the fix.
Differential Revision: https://phab.mercurial-scm.org/D11239
contrib: switch the Windows bootstrap environment to py3.9
Use the built in `venv` module instead of `virtualenv` for simplicity, and
upgrade to a modern Mercurial that supports py3.
One issue here is that `venv` doesn't copy `python3{,Y}.dll` into the `Scripts`
subdirectory, so running the `hg.exe` that gets installed immediately fails on a
clean system because Python isn't in `PATH`. There is code in `python.exe` to
detect when it is in a venv and add the original python install to the DLL
lookup path, which we don't do in `hg.exe` yet. The simple workaround for now is
to run the `hg` script with `python.exe`. Typically `PYTHONLEGACYWINDOWSSTDIO`
must be set in the environment on Windows, but the clone process works without
it.
Differential Revision: https://phab.mercurial-scm.org/D11275