Commits on Source (55)
-
Euxane TRAN-GIRARD authored
Recent versions of git restrict the use of the "file" protocol for security reasons (https://github.com/git/git/commit/a1d4f67). This broke this test, which failed with the following hidden error: "fatal: transport 'file' not allowed". This patch relaxes the git configuration for the test to solve this.
2b658c6a9c4b -
Pierre-Yves David authored
The release was tagged "6.3.0" while the custom have been to omit the third ".0" for initial release for the history of the project. For consistency, we add the customary version of the tag to the 6.3 release.
9e5b411b3b19 -
Anton Shestakov authored
In case the tests are run as root, ls assumes -A by default on some systems (e.g. NetBSD). Tests probably shouldn't be run as root, but let's use -A just in case, for convenience.
12efb17faee2 -
Anton Shestakov authored
This is done to make it's clear that windows is not affected by this test case, IOW windows and non-windows platforms are now tested separately, because their results are very different.
e11760daee12 -
Anton Shestakov authored
On Linux, ls -A simply returns nothing and the exit code is 0. On NetBSD, ls -A complains that . doesn't exist and the exit code is 1. Sadly, it's not possible to do something like "[1] (?)", so " || true" is the best I could come up with.
88a8de821b5e -
Raphaël Gomès authored
Being this rigid makes packagers' job more difficult since they might not carry the exact version. This hard pinning was introduced in eb02decdf0ab but wasn't strictly necessary to achieve its compatibility goal.
b78ae134ac92 -
Matt Harbison authored
I noticed because `merge-pyi` on the non-cext implementations with this file as input skipped the return type for this. `pytype-single --parse-pyi` confirmed it was a problem.
b8389533ba3a -
Matt Harbison authored
This was flagged by pytype after merging the corresponding bdiff.pyi in cext: File ".../mercurial/cffi/bdiff.py", line 44, in blocks: bad return type [bad-return-type] Expected: List[Tuple[int, int, int, int]] Actually returned: List[None] AFAICT, all callers immediately unpack the tuple into 4 variables, so a `None` entry would simply crash if they aren't all overwritten. As long a `count` and the link list are consistent, this shouldn't be a problem. This placates both pytype and PyCharm (which complained about the `i` in `rl[i]` having the wrong type with the old code).
b2666e767029 -
Matt Harbison authored
Not super important code, but this was an exercise in using `merge-pyi` to fold type stubs back into the code on something small. The cext stubs don't seem to be getting used (at least the only thing in `.pytype/pyi/mercurial/cext` after a run generating the stubs is `__init__.pyi`), so maybe this will help some.
594fc56c0af7 -
Matt Harbison authored
Again, using `merge-pyi` to apply the stubs in cext and then manually type the private methods. The generated stub without these hints inferred very little, and the stuff it did was wrong.
94a797032fc4 -
Matt Harbison authored
The cffi and pure implementations both default to `None`, and the args are parsed in C with `"y#|OO:listdir"`, with the C variable initialized to NULL.
b6fc602e074a -
Matt Harbison authored
This code hasn't been touched in recent years, and the other implementation return bytes for the filename, so I assume this is a holdover from the py2 days. I was unable to test it on mac though, because the `_osutil` import failed.
8009a89bc18b -
Pierre-Yves David authored
The revision having two tags confuses some of the build script trying to fetch the version. So, remove the "bad" tag for now.
4e3d86565327 -
Pierre-Yves David authored
Python 3.11 is now enforcing that flag must be at the beginning of the regex This creates a serious regression for people using Python 3.11 with an hgignore using flag in a "relre" pattern. We now detect any flags in such pattern and "prepend" our ".*" pattern after them. In addition, we now insert the flag in the regexp to only affect the pattern we are rewriting. Otherwise, the regex built from the combined pattern would these flags in the middle of it anyway. As a side effect of this last change, we fix a bug… before this change regex flag in a pattern would affect all combined patterns. That was bad and is not longer the case. The Rust code needs to be updated to fix that very bug, but we will do it in another changeset.
3eda36e9b3d6 -
Pierre-Yves David authored
Same problem same solution.
086b0c4f8663 -
Pierre-Yves David authored
Since the previous commit (fixing wider issue), the code generated strange regex. This is now fixed and tested.
b3480822a251 -
Jason R. Coombs authored
Also, add some documentation to the `.in` files.
4092db99541a -
Matt Harbison authored
This code hasn't been touched in recent years, and the other implementation return bytes for the filename, so I assume this is a holdover from the py2 days. I was unable to test it on mac though, because the `_osutil` import failed.
d122c8fda5a0 -
Pierre-Yves David authored
This will help us to understand the behavior of find-delta during a pull.
78ba41878f2e -
Pierre-Yves David authored
This will helps a lot to understand how the bundling decision might impact pull/unbundle on the other side.
9cac281eb9c0 -
Pierre-Yves David authored
This will helps a lot to understand how the bundling decision have actually impacted pull/unbundle on the other side.
35d4c2124073 -
Pierre-Yves David authored
This make the next changeset more compact.
2afee2176775 -
Pierre-Yves David authored
This is more consistent and will help use to be in a clean state before dealing with the "too large group" issue. As a side effect, the debug output now skip some useless cases, making it more useful.
e706bb41fdb3 -
Pierre-Yves David authored
This is not a 1-1 mapping, but a 1-n mapping. Lets make the associated comment clearer.
5447c1507c86 -
Pierre-Yves David authored
the index in the delta-chain is also the snapshot depth. So we rename the variable for clarity.
01ccb45b7393 -
Pierre-Yves David authored
In a coming change, not all elements of `group` might get tested. So we need to have more control about when a revision is actually added to the `tested` set. So we move to a more verbose (and more fragile) version.
4956942c0416 -
Arseniy Alekseyev authored2af928d69e8e
-
Matt Harbison authored7ddbb3623a07
-
Matt Harbison authored
It looks like this is meant to prevent adding another commit that does nothing but close a branch on top of a commit that already closed the branch. The matcher building functions want `Dict[bytes, Any]`, not `Dict[str, Any]`, which was found by adding type hints to the matcher related methods in scmutil.
3adca6eb6659 -
Arseniy Alekseyev authored
since the transaction reverts the store, while the dirstate is stored separately
302dd8ae2745 -
Arseniy Alekseyev authored8cd39c20445e
-
Arseniy Alekseyev authored
This is useful so we can store other files in $TESTTMP (in particular tests that use docket files (nodemap, dirstate-v2) keep file uids in $TESTTMP/UID)
55c6ebd11cb9 -
Pierre-Yves David authored
When running `hg log --follow --rev REVS FILES`, the log code will walk the history of all FILES starting from the file revisions that exists in each REVS. Before doing so, it looks if the files actually exists in the target revisions. To do so, it opens the manifest of each revision in REVS to look up if we find the associated items in FILES. Before this changeset this was done in a way that created a changectx for each target revision, keeping them in memory while we look into each file. If the set of REVS is large, this means keeping the manifest for each entry in REVS in memory. That can be large… if REV is in the form `::X`, this can quickly become huge and saturate the memory. We have seen usage allocating 2GB per second until memory runs out. So this changeset invert the two loop so that only one revision is kept in memory during the operation. This solve the memory explosion issue.
dcb2581e33be -
Pierre-Yves David authored
This one is not covered by the CIbecause I requires an expensive artifact to be cached. So it goes out of think on regular basis (we should fix that…) The test ouput was affected by e706bb41fdb3 as we filtering now happens sooner, removing for the output.
da636e7a6d63 -
Raphaël Gomès authoredc890d8b8bc59
-
Raphaël Gomès authored010d9e362ee4
-
Raphaël Gomès authored3324f39460e5
-
Raphaël Gomès authored7577b8644558
-
Raphaël Gomès authored
A few months ago¹, a decision was made to move the Rust toolchain target to whatever Debian Testing was tracking. I didn't have the bandwidth to act on it until now. This is starting to be even more problematic than before, now that edition 2021 is out. The CI has been updated to track the current Debian testing version, 1.61.0. [1] https://lists.mercurial-scm.org/pipermail/mercurial-packaging/2022-April/000338.html
eb383f093a01 -
Raphaël Gomès authored
We've changed our minimum Rust version to 1.61.0 in the previous patch, and edition 2021 predates that version.
1b6be761c23d -
c7fb9b74e753
-
Raphaël Gomès authored29cf3167e459
-
Raphaël Gomès authored048f829a445a
-
Raphaël Gomès authoredec399ddf6764
-
Raphaël Gomès authored4d729a98673d
-
Raphaël Gomès authored
Now that we support a newer version of Rust, we can update this dependency to get all the latest bugfixes and improvements. A slight API adjustment was needed.
a5447a4a8c5d -
Raphaël Gomès authored
Upgrading is a finally possible now that we're supporting a more recent version of Rust. This required changes in the `nodemap` example.
14bfd22a57a9 -
Raphaël Gomès authored
Finally, these dependencies do not require any code changes, so they are all grouped in the same changeset.
9726deed397c -
Raphaël Gomès authored
`hg-cpython` has no BC breaking dependencies, we can group them all in this changeset.
5844cd8e81ca -
Raphaël Gomès authored
This one is the worst one to upgrade since v2 -> v4 broke a ton of API, which thankfully seems saner now. Contrary to what was done in the `hg-core/src/examples/nodemap` rewrite, we're not switching from the "builder" pattern to the "derive" pattern, since that would imply a much larger diff. It can be done incrementally.
37bc3edef76f -
Raphaël Gomès authored
These are painless, so they are all grouped in this changeset.
ab6151e1f468 -
Matt Harbison authored
When updating to 22.1.0, this test started failing: Traceback (most recent call last): File "/tmp/mercurial-ci/tests/test-util.py", line 53, in <module> _start_default = (util.timedcmstats.start.default, 'factory') AttributeError: type object 'timedcmstats' has no attribute 'start' Poking around in `hg debugshell`, the attribute is indeed missing, but looks to be attached to `__attrs_attrs__` in both the currently vendored and the modern version of attrs. The old attrs packages will print the same for both accesses, so fingers crossed... >>> print((util.timedcmstats.start.default, 'factory')) (Factory(factory=<function timedcmstats.<lambda> at 0x000001EFDF0F21F0>, takes_self=False), 'factory') >>> print((util.timedcmstats.__attrs_attrs__.start.default, 'factory')) (Factory(factory=<function timedcmstats.<lambda> at 0x000001EFDF0F21F0>, takes_self=False), 'factory')
7e6f3c69c0fb -
Matt Harbison authored
The previous version was 5 years old, and pytype 2022.06.30 started complaining about various uses (e.g. seeing `mercurial.thirdparty.attr._make._CountingAttr` instead of `bytearray`). Hopefully this helps. Additionally, this has official python 3.11 support. The `attrs` package is left out, because it is simply a bunch of *.pyi stubs and `from attr.X import *`, and that's not how they've been used up to this point. We'd probably need to customize those anyway to `from mercurial.thirdparty.attr import *`.
e1c586b9a43c -
Matt Harbison authored
When trying to figure out how `hg help -v` took the Set interpolation path in f09bc2ed9100, I turned on devel warnings and noticed this (unrelated) warning: devel-warn: specifying a mismatched default value for a registered config item: 'merge-tools.beyondcompare4.regappend' '' at: c:\Users\Matt\hg\mercurial\filemerge.py:46 (_toolstr) The previous default value for this config was `None`, but that slightly complicates the code at the only site it is used, referenced above.
5744ceeb9067 -
Matt Harbison authored
Was hoping to find more issues like f09bc2ed9100, but it may be that nothing checks the args to that operation. In any event, the work is done and pytype doesn't do a very good job inferring the types. A few of th emore complicated things like the command table are left untyped, because they come from modules that aren't typed yet.
2a70d1fc70c4
Showing
- .hgsigs 1 addition, 0 deletions.hgsigs
- .hgtags 4 additions, 0 deletions.hgtags
- contrib/packaging/requirements-windows-py3.txt 5 additions, 3 deletionscontrib/packaging/requirements-windows-py3.txt
- contrib/packaging/requirements-windows.txt.in 6 additions, 0 deletionscontrib/packaging/requirements-windows.txt.in
- contrib/packaging/requirements.txt 21 additions, 2 deletionscontrib/packaging/requirements.txt
- contrib/packaging/requirements.txt.in 3 additions, 0 deletionscontrib/packaging/requirements.txt.in
- hgext/remotefilelog/remotefilelog.py 1 addition, 0 deletionshgext/remotefilelog/remotefilelog.py
- hgext/sqlitestore.py 1 addition, 0 deletionshgext/sqlitestore.py
- mercurial/cext/bdiff.pyi 1 addition, 1 deletionmercurial/cext/bdiff.pyi
- mercurial/cext/osutil.pyi 2 additions, 1 deletionmercurial/cext/osutil.pyi
- mercurial/cffi/bdiff.py 8 additions, 3 deletionsmercurial/cffi/bdiff.py
- mercurial/cffi/mpatch.py 3 additions, 1 deletionmercurial/cffi/mpatch.py
- mercurial/cffi/osutil.py 1 addition, 1 deletionmercurial/cffi/osutil.py
- mercurial/changegroup.py 455 additions, 10 deletionsmercurial/changegroup.py
- mercurial/commands.py 3 additions, 1 deletionmercurial/commands.py
- mercurial/configitems.py 19 additions, 0 deletionsmercurial/configitems.py
- mercurial/dirstatemap.py 0 additions, 2 deletionsmercurial/dirstatemap.py
- mercurial/filelog.py 4 additions, 0 deletionsmercurial/filelog.py
- mercurial/filemerge.py 1 addition, 1 deletionmercurial/filemerge.py
- mercurial/help.py 95 additions, 44 deletionsmercurial/help.py
This diff is collapsed.