- Oct 28, 2021
-
-
Pierre-Yves David authored
The previous code was overlooking fallback when neither symlink not exec was supported. The number of "variants" is getting too high, so I am consolidating this in a single closure that should be easier to maintains. This also ensure that fallback flags are always taken into account. (they are not user code yet, but small experimentation shown that the feature was working as intended.) A a small side effect we need to check for symlink support more lazily and this show up in the test in a couple of places. Differential Revision: https://phab.mercurial-scm.org/D11728
-
- Oct 26, 2021
-
-
Augie Fackler authored
-
Pulkit Goyal authored
-
Pulkit Goyal authored
-
- Oct 25, 2021
-
-
Raphaël Gomès authored
Differential Revision: https://phab.mercurial-scm.org/D11720
-
- Oct 23, 2021
-
-
Matt Harbison authored
These were found by looking for `Any` types in the generated `*.pyi` file after running the tests. There are some more complicated types that I'm not sure of, and am leaving untyped. I also can't figure out how to get `self.hint` to be anything other than `Any` in most classes. Differential Revision: https://phab.mercurial-scm.org/D11719
-
Matt Harbison authored
I've seen this before, but this was seen as potentially `None` with pytype 2021.10.18. Differential Revision: https://phab.mercurial-scm.org/D11718
-
- Oct 21, 2021
-
-
Raphaël Gomès authored
As suggested by spectral during review of my fix of the missing return, this makes it more obvious that all cases are covered and improves readability of the functions with new names and a small docstring. Differential Revision: https://phab.mercurial-scm.org/D11715
-
- Oct 20, 2021
-
-
Raphaël Gomès authored
Differential Revision: https://phab.mercurial-scm.org/D11713
-
Raphaël Gomès authored
Otherwise the compiler gets quite sad. Differential Revision: https://phab.mercurial-scm.org/D11712
-
Raphaël Gomès authored
Otherwise the compiler gets quite sad. Differential Revision: https://phab.mercurial-scm.org/D11711
-
Kyle Lippincott authored
A recent change to git (031e2f7ae195) made it an error to not specify a strategy (`--rebase`, `--no-rebase`, `--ff-only`), instead of just the warning it was previously. As far as I can tell, `--no-rebase` is the behavior we were getting before, and the only one that makes the test work. Differential Revision: https://phab.mercurial-scm.org/D11714
-
- Oct 21, 2021
-
-
Raphaël Gomès authored
-
Raphaël Gomès authored
`HGTEST_TIMEOUT` is overridden by `HGTEST_SLOWTIMEOUT` for tests marked as slow, which `test-check-pytype.t` is. So this whole time the timeout was 1500s (or 25 minutes), which is unfortunately not long enough for a *lot* of the times it's run on the CI. Differential Revision: https://phab.mercurial-scm.org/D11717
-
- Oct 20, 2021
-
-
Arseniy Alekseyev authored
chg tests fail pretty often with "Sample count: *" line disappearing. It disappears because the sample count is zero, in which case a custom message is printed. This commit makes the test succeed in that case. Differential Revision: https://phab.mercurial-scm.org/D11716
-
- Oct 21, 2021
-
-
David Demelier authored
Per 7.1.3 paragraph, from C draft: All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
-
- Oct 19, 2021
-
-
Raphaël Gomès authored
The `unittest._TextTestResult` alias has been removed. The "new" name has been available since 3.2, and we only support 3.5.3+. Differential Revision: https://phab.mercurial-scm.org/D11690
-
- Oct 20, 2021
-
-
Raphaël Gomès authored
Mercurial is not (yet) a pep517 package, but the presence of a pyproject.toml file tells newer-ish versions of pip that it should be one. This is related to 58fe6d127a01, and fixes pyoxidizer builds for the Heptapod CI. Differential Revision: https://phab.mercurial-scm.org/D11710
-
- Oct 19, 2021
-
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D11706
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D11705
-
Georges Racinet authored
This is a backout of changeset 3fffb48539ee. Issue 6554 is now considered solved, hence its mitigation has to be removed, if only for its performance cost. Differential Revision: https://phab.mercurial-scm.org/D11703
-
- Oct 18, 2021
-
-
Kyle Lippincott authored
Currently, pyoxidizer.bzl does not mention the git commit that should be checked out, so these instructions are a bit difficult to follow right now (impossible, technically), so I removed the instruction to `git checkout <Git commit>` and the admonition to use a specific version of PyOxidizer. I don't even know if the project currently builds with the "0.7.0-pre" version that was previously recommended. As fallout from that change to not "pin" to a specific PyOxidizer, I had to update the Python version to use when running the tests. While here, I added a recommendation to use `--release`, as the primary reason for this project is performance, and it may have been leaving some on the table to not have that there. Differential Revision: https://phab.mercurial-scm.org/D11698
-
Kyle Lippincott authored
It's possible that the errors are due to using an incompatible version of PyOxidizer; unfortunately the README.md file in this directory says to fetch a copy of PyOxidizer matching the commit in this pyoxidizer.bzl file, and yet the pyoxidizer.bzl file does not actually have a commit mentioned in it. By disabling in-memory modules, this appears to work on all platforms using the current head version of PyOxidizer, so let's disable them for now. Sample error (during `pyoxidizer build`): ``` error[PYOXIDIZER_PYTHON_EXECUTABLE]: adding PythonExtensionModule<name=hgext.fsmonitor.pywatchman.bser> Caused by: extension module hgext.fsmonitor.pywatchman.bser cannot be loaded from memory but memory loading required --> ./pyoxidizer.bzl:140:5 | 140 | exe.add_python_resources(exe.pip_install(["--verbose", ROOT])) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ add_python_resources() error: adding PythonExtensionModule<name=hgext.fsmonitor.pywatchman.bser> Caused by: extension module hgext.fsmonitor.pywatchman.bser cannot be loaded from memory but memory loading required ``` Differential Revision: https://phab.mercurial-scm.org/D11697
-
- Oct 19, 2021
-
-
Pierre-Yves David authored
Since the format is not frozen yet, it seems like the right moment to do it. Differential Revision: https://phab.mercurial-scm.org/D11704
-
Pierre-Yves David authored
This was overlooked in a previous commit. Differential Revision: https://phab.mercurial-scm.org/D11695
-
Pierre-Yves David authored
Tracking directory "explicitly" give use the opportunity to distinct between entry that are untracked because they are part of the directory structure and entry that are ignored/unknown files on the files system. The help is adjusted to the new semantic and the code now comply to it for both read and write. Differential Revision: https://phab.mercurial-scm.org/D11694
-
- Oct 13, 2021
-
-
Simon Sapin authored
Instead of zero, set the nanoseconds field to its correct value whenever possible and preserve it across serialization+parsing. Differential Revision: https://phab.mercurial-scm.org/D11702
-
- Oct 14, 2021
-
-
Simon Sapin authored
When comparing mtimes for equality. Some APIs simply return zero when more precision is not available. When comparing values from different sources, if only one is truncated in that way, doing a simple comparison would cause many false negatives. Differential Revision: https://phab.mercurial-scm.org/D11701
-
- Oct 19, 2021
-
-
Pierre-Yves David authored
This flag will let us use more `mtime` value in the future. For now we have a minimal handling of the flag at read time, but we will never put ourself in a situation where we will needs to writes it. See the flag documentation for details. Differential Revision: https://phab.mercurial-scm.org/D11700
-
- Oct 18, 2021
-
-
Simon Sapin authored
Keep integer seconds since the Unix epoch, together with integer nanoseconds in the `0 <= n < 1e9` range. For now, nanoseconds are still always zero. This commit is about data structure changes. Differential Revision: https://phab.mercurial-scm.org/D11684
-
- Oct 19, 2021
-
-
Simon Sapin authored
Differential Revision: https://phab.mercurial-scm.org/D11696
-
Pierre-Yves David authored
The rest of the code use this name. It is not a great name, but it is better to stay consistent. Differential Revision: https://phab.mercurial-scm.org/D11699
-
- Oct 18, 2021
-
-
Simon Sapin authored
No need to oversell it. Differential Revision: https://phab.mercurial-scm.org/D11691
-
- Oct 19, 2021
-
-
Raphaël Gomès authored
After discussion on the original phab patch, we've decided to wait until Python 2 support is dropped to do this since the behavior differs for relatively obscure reasons. Differential Revision: https://phab.mercurial-scm.org/D11692
-
Raphaël Gomès authored
Same as the previous changeset. Differential Revision: https://phab.mercurial-scm.org/D11693
-
- Oct 18, 2021
-
-
Pierre-Yves David authored
When the fallback values are set, they are now read and written to disk. See format documentation for details. Differential Revision: https://phab.mercurial-scm.org/D11688
-
Pierre-Yves David authored
This could arguably goes in the previous changeset, but I wanted to keep that previous changeset small to focus more on the user code and the documentation. Differential Revision: https://phab.mercurial-scm.org/D11687
-
Pierre-Yves David authored
The concept is defined and "used" by the flag code, but it is neither persisted nor set anywhere yet. We currently focus on defining the semantic of the attribute. More to come in the next changesets Check the inline documentation for details. Differential Revision: https://phab.mercurial-scm.org/D11686
-
- Oct 15, 2021
-
-
Pierre-Yves David authored
Right now, we don't record ignored or unknown files in the dirstate. However the structure would allow it. So we introduce two flags that can be used to clarify whether all unknown/ignored children are recorded or not. This will allow for more information to be stored in the future if this end up being relevant. Differential Revision: https://phab.mercurial-scm.org/D11682
-
Simon Sapin authored
Right now, a files with a file system state that requires a lookup (same size, different mtime) will requires a lookup. If the result of that lookup is a modified files, it will remains ambiguous, requiring a lookup on the next status run too. To fix this, we introduce a dedicated flag in the new format. Such flag will allow to record such file as "known modified" avoiding an extra lookup later. As None of the associate code currently exist in the status code, we do the minimal implementation: if we read a dirstate entry with this flag set, we make it as "ambiguous" so that the next status code has to look it up. The same as it would have to without this flag existing anyway. Differential Revision: https://phab.mercurial-scm.org/D11681
-