- Feb 17, 2023
-
-
Pierre-Yves David authored
This is the stable counter part to e358f6e0e50e. Since 6.4 will stop writing undo.dirstate in some case (actually… at all), a transaction created with 6.4 and recover/rolledback with 6.3 need to work to a certain degreee. This changeset add the necessary bits so that we don't get a traceback from 6..3 in this cases.
-
- Feb 16, 2023
-
-
Pierre-Yves David authored
I now get about 80% of my `test-chg` CI run that fails on flakyness in this tests. It turns out this is only ambiguous status that end up doing file download. So… calling status early will do that potential download separately and the calls we scrutinize during that test will be just fine.
-
- Feb 03, 2023
-
-
Pierre-Yves David authored
The previous debug output did not help to understand which file where fixed in which revision. The new output should cover that.
-
Matt Harbison authored
The environment seems to be `str` or `tuple[int]`, and the same check in `wsgicgi.py` is already `str` based, so I suspect this was wrong. I think what happened here is that the string wasn't `r''` prefixed in 482d6f6dba91 like `wsgicgi.py`, so it got wrongly byteified in 687b865b95ad when converting to byte literals en masse.
-
- Jan 30, 2023
-
-
Pierre-Yves David authored
Choking on Mercurial's stderr mean armless warning can derails the whole install process. We do like to be able to issue warning to people so we stop considering any stderr is a fatal mistake. This allow us to actually boostrap a version of Mercurial without loosing to many sanity point. For example in case where evolve is not loaded, something that happens when the recorded version is malformatted. Creating a wonderful ouroboros.
-
Pierre-Yves David authored
The tag fetching might return and empty string¹, from there everything derails quickly. As setup tools becomes more picky about version format we make the whole seems a bit more robust. The resulting version will be obviously weird, but at least it will actually install itself. [1] This is a problem we will address in the next changesets.
-
Matt Harbison authored
Previously, `hg log -r 'bundle()' -R bundle.hg` was failing for me when run from source, complaining about an unknown parent, when the system installed `hg` didn't. Some debugging showed the index was 0 length. It turned out that I didn't have the C extensions compiled, which a simple `hg log -r .` was able to indicate. The problem being that the RequirementError got handled by RepoError, which uses an empty directory as a fallback to process the bundle.
-
- Jan 28, 2023
-
-
Anton Shestakov authored
-
- Jan 09, 2023
-
-
Raphaël Gomès authored
This was caught by `clippy`. I guess the narrow tests leave something to be desired, since this previously only checked the first valid pattern.
-
- Jan 25, 2023
-
-
Anton Shestakov authored
-
Anton Shestakov authored
There are 3 of them, and them all having the same name triggered code checkers.
-
Anton Shestakov authored
-
Anton Shestakov authored
This .t file was failing for me when running run-tests.py with python3.11. Then I tried to run it with python3.10 and it failed anyway, even though it's the default python3 interpreter. But with `python3 ./run-tests.py` it worked fine. And this is what I found while looking at the way pygments lexer checks if a file without extension is likely to be a python script: shebang_matches(text, r'pythonw?(3(\.\d)?)?') Take guess why it doesn't work for python >= 3.10. To work around this issue, we can simply hardcode an "easier" shebang for pygments. This path to python interpreter obviously doesn't need to be accurate, since we're not running this script.
-
Anton Shestakov authored
-
- Dec 06, 2022
-
-
Julien Cristau authored
-
- Jan 23, 2023
-
-
Raphaël Gomès authored
Our CI currently runs on a number of different runners, some of which are run by Clever Cloud. By setting this environement variable, we're asking for a smaller size runner for our smaller jobs, which puts less load on the Clever Cloud infrastructure, while not affecting our overall pipeline times.
-
- Jan 12, 2023
-
-
Anton Shestakov authored
This avoids DeprecationWarnings related to our use of resources.open_binary() on Python 3.11.
-
- Jan 10, 2023
-
-
Anton Shestakov authored
I guess we figured out why it wasn't lazy.
-
Anton Shestakov authored
-
- Jan 13, 2023
-
-
Anton Shestakov authored
-
- Jan 12, 2023
-
-
Anton Shestakov authored
'r+' mode used to open sockets for read/write operations, but '+' is not supported in Python 3. We're using bytes with these sockets everywhere, so the mode should have 'b'. But the mode argument has to be str, not bytes.
-
Anton Shestakov authored
Since root is bytes, the regular expression should also be bytes.
-
- Jan 06, 2023
-
-
Matt Harbison authored
I'm sure there's a bunch more stuff in here that's broken, but this was flagged by pytype.
-
Matt Harbison authored
In a local pytype run, this fixes: File "/mnt/c/Users/Matt/hg/hgext/sparse.py", line 386, in debugsparse: unsupported operand type(s) for item retrieval: 'fcounts: Iterator[int]' and '0: int' [unsupported-operands] No attribute '__getitem__' on 'fcounts: Iterator[int]' File "/mnt/c/Users/Matt/hg/hgext/sparse.py", line 387, in debugsparse: unsupported operand type(s) for item retrieval: 'fcounts: Iterator[int]' and '1: int' [unsupported-operands] No attribute '__getitem__' on 'fcounts: Iterator[int]' File "/mnt/c/Users/Matt/hg/hgext/sparse.py", line 388, in debugsparse: unsupported operand type(s) for item retrieval: 'fcounts: Iterator[int]' and '2: int' [unsupported-operands] No attribute '__getitem__' on 'fcounts: Iterator[int]'
-
- Jan 05, 2023
-
-
Matt Harbison authored
While there's some allowance for str in `_()`, it's commented to be for "goofy unicode docstrings in test", so no idea how well that works, but it should at least come back as bytes. With HGPLAIN, however, the str isn't touched and is returned as-is, so this seems like a real bug.
-
- Jan 09, 2023
-
-
Anton Shestakov authored
-
Anton Shestakov authored
-
- Jan 04, 2023
-
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
- Jan 03, 2023
-
-
Martin von Zweigbergk authored
Without this patch, you'd get `mercurial.error.ProgrammingError: fileset expression with no context`.
-
- Dec 06, 2022
-
-
Matt Harbison authored
Otherwise, we get a bunch of test failures for missing things like pygments, or tests skipped entirely. The input file is a copy/paste from the equivalent Windows file, but with dulwich, pygit2, and pytest-vcr commented out because the build process errors out with them, flagging them as incompatible with loading from memory. I have no idea if that's actually true or not, because I've noticed that if I don't `make clean` after every build, the next build flags the watchman stuff as incompatible with loading from memory. The remaining failures are: Failed test-alias.t: output changed Failed test-basic.t: output changed Failed test-check-help.t: output changed Failed test-commit-interactive.t: output changed Failed test-extension.t: output changed Failed test-help.t: output changed Failed test-i18n.t: output changed Failed test-log.t: output changed Failed test-qrecord.t: output changed Failed test-share-safe.t: output changed Most of the issues seem related to loading help for disabled extensions from `hgext.__index__`, namely the full extension help being unavailable, not being able to resolve what commands are provided by what extension, and not having the command level help available. test-log.t, test-commit-interactive.t, and test-i18n.t look like i18n (or lack thereof) issues. test-basic.t is just odd: @@ -55,7 +55,7 @@ On Python 3, stdio may be None: $ hg debuguiprompt --config ui.interactive=true 0<&- - abort: Bad file descriptor (no-rhg !) + abort: response expected abort: response expected (rhg !) [255] $ hg version -q 0<&-
-
Matt Harbison authored
-
Matt Harbison authored
The in-memory pyoxidizer builds apparently behave as expected.
-
Matt Harbison authored
There are a handful of tests with different output between the two flavors of pyoxidizer builds (like the location of the modules and templates), and a few others that avoid `known-bad-output` cases with the embedded resources that shouldn't cause the tests to fail.
-
- Dec 05, 2022
-
-
Matt Harbison authored
We should definitely be able to test this before releasing it with an installer.
-
Matt Harbison authored
The resources seem to be embedded inside the binary, but for some reasons they aren't read there. And since they are embedded, they aren't staged by the build in the `lib` directory like on Windows. So copy them from the repo. We can figure out what's going wrong later.
-
- Jan 02, 2023
-
-
Matt Harbison authored
-