Wed, 11 Sep 2024 00:20:07 +0200 ci: also offer to test 3.12 with rust
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 11 Sep 2024 00:20:07 +0200] rev 51847
ci: also offer to test 3.12 with rust The rust-cpython binding got 3.12 support very recently, it is worse keeping on a tighter watch.
Wed, 28 Aug 2024 16:35:43 +0200 ci: add the option to test more Python versions
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 28 Aug 2024 16:35:43 +0200] rev 51846
ci: add the option to test more Python versions It seems like a good idea to be able to test the lowest version we support. And there have been enougth issue with 3.12 that we need to be able to make sur we do not break it. We should probably get a matrix setup for more version and flavor, but that is a simple and efficient start.
Thu, 05 Sep 2024 12:37:59 +0200 censor: document the censor.policy option (issue6909)
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 05 Sep 2024 12:37:59 +0200] rev 51845
censor: document the censor.policy option (issue6909) Censor is not marked as experimental and should be documented I am not doing this on stable because the help markup change it is using seems more suitable for default.
Thu, 05 Sep 2024 12:28:12 +0200 help: add :config-doc:`section.key` shorthand to insert documentation
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 05 Sep 2024 12:28:12 +0200] rev 51844
help: add :config-doc:`section.key` shorthand to insert documentation The config items defined in the configitems.toml file can already hold their documentation. Having some way to automatically insert it was a long standing low hanging fruit. So I did a first implementation on that. It fairly simple, but it open the door to more. It will be used in the next changeset.
Wed, 11 Sep 2024 20:52:51 +0200 bzr: attempt to stabilize the test
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 11 Sep 2024 20:52:51 +0200] rev 51843
bzr: attempt to stabilize the test The test has flakyness where the order of a few commit swap. This is an attempt at avoiding that.
Thu, 12 Sep 2024 02:24:20 +0200 branching: merge with stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 12 Sep 2024 02:24:20 +0200] rev 51842
branching: merge with stable
Wed, 11 Sep 2024 12:03:39 +0200 profiling: use "stat" profiler to profile individual request stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 11 Sep 2024 12:03:39 +0200] rev 51841
profiling: use "stat" profiler to profile individual request The ls profiler no longer works for that. As the lsprof profiler is not default and not great is general, lets side step the issue for now.
Wed, 11 Sep 2024 12:02:38 +0200 profiling: improve 3.12 error message for calling lsprof twice stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 11 Sep 2024 12:02:38 +0200] rev 51840
profiling: improve 3.12 error message for calling lsprof twice Python 3.12 prevent lsprof to be enabled if it is already enabled. This break the use of lsprof in `hg serve` as both the initial `serve` command and the request serving want to profile. The "stat" profiler (the default) does not have this problem, so we focus on improving the error message for now.
Wed, 11 Sep 2024 00:41:37 +0200 test: display server error log in test-profile.t stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 11 Sep 2024 00:41:37 +0200] rev 51839
test: display server error log in test-profile.t This will help us to catch error with Python 3.12
Wed, 15 Nov 2023 22:11:34 +0100 archive: defer opening the output until a file is matched
Joerg Sonnenberger <joerg@bec.de> [Wed, 15 Nov 2023 22:11:34 +0100] rev 51838
archive: defer opening the output until a file is matched Before, if no file is matched, an error is thrown, but the archive is created anyway. When using hgweb, an error 500 is returned as the response body already exists when the error is seen. Afterwards, the archive is created before the first match is emitted. If no match is found, no archive is created. This is more consistent behavior as an empty archive is not a representable in all output formats, e.g. tar archives.
Thu, 05 Sep 2024 13:37:24 +0200 run-tests: add color to the progress output
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 05 Sep 2024 13:37:24 +0200] rev 51837
run-tests: add color to the progress output More color is useful to me.
Tue, 10 Sep 2024 22:26:23 +0200 python-compat: drop support for Python3.6 and 3.7
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 10 Sep 2024 22:26:23 +0200] rev 51836
python-compat: drop support for Python3.6 and 3.7 As discussed on the mailing list¹, these are old version that seems safe to drop. Python 3.8 comes with various improvement especially regarding typing capabilities. [1] https://lists.mercurial-scm.org/pipermail/mercurial-devel/2024-July/297998.html
Tue, 10 Sep 2024 21:19:36 +0200 ci: drop path manipulation that we do not need anymore
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 10 Sep 2024 21:19:36 +0200] rev 51835
ci: drop path manipulation that we do not need anymore The CI image has a squarer setup now.
Fri, 06 Sep 2024 02:12:19 +0200 brancing: merge stable into default
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 06 Sep 2024 02:12:19 +0200] rev 51834
brancing: merge stable into default
Thu, 05 Sep 2024 15:37:14 -0400 setup: handle removal of old MSVC compiler from setuptools 65.0 (issue6910) stable
Matt Harbison <mharbison@atto.com> [Thu, 05 Sep 2024 15:37:14 -0400] rev 51833
setup: handle removal of old MSVC compiler from setuptools 65.0 (issue6910) It was removed a few years ago[1]. When trying to reproduce locally using a clean py3.12 as called out in the bug report, `setuptools` wasn't installed at all, and needed a `pip install` to fix a `ModuleNotFoundError` when building locally. Maybe that needs to be in the requirements clause now. It looks like this "private" module was added in setuptools 48.0.[2] I can't find a changelog of what version was included in which version of python, and the changelog for pip has a huge gap between when it called out 67.6.1 in `pip` 23.1 (2023-04-15), and 41.4.0 in `pip` 19.3 (2019-10-14).[3] So, we'll just add to the existing code instead of replacing it, for safety. [1] https://github.com/pypa/setuptools/commit/cc017c77948737d131f683e0c25cd37bc639b8fc [2] https://github.com/pypa/setuptools/commit/d034a5ec7f707499139f90eb846b9e720923124c [3] https://pip.pypa.io/en/stable/news/
Wed, 28 Aug 2024 23:25:26 +0200 utils: accept bytearray arguments for escapestr
Joerg Sonnenberger <joerg@bec.de> [Wed, 28 Aug 2024 23:25:26 +0200] rev 51832
utils: accept bytearray arguments for escapestr
Sun, 30 Jun 2024 16:02:50 +0200 http: simplify
Joerg Sonnenberger <joerg@bec.de> [Sun, 30 Jun 2024 16:02:50 +0200] rev 51831
http: simplify
Sun, 30 Jun 2024 14:16:43 +0200 http: use urllib's cookie handler
Joerg Sonnenberger <joerg@bec.de> [Sun, 30 Jun 2024 14:16:43 +0200] rev 51830
http: use urllib's cookie handler Split the logic for loading the cookies based on the configuration in a helper function and otherwise use the library implementation directly.
Sun, 30 Jun 2024 13:22:23 +0200 http: reuse Python's implementation of read/readline/readinto
Joerg Sonnenberger <joerg@bec.de> [Sun, 30 Jun 2024 13:22:23 +0200] rev 51829
http: reuse Python's implementation of read/readline/readinto Since Python 3 already provides a working implementation of readline, there is no need for our own buffering implementation. Reduce the code to transfer accounting only.
Sun, 30 Jun 2024 02:46:53 +0200 debugwireproto: redo logging to also work for https
Joerg Sonnenberger <joerg@bec.de> [Sun, 30 Jun 2024 02:46:53 +0200] rev 51828
debugwireproto: redo logging to also work for https
Fri, 28 Jun 2024 16:26:06 +0200 urllib2: redo response.readlines addition via class patching
Joerg Sonnenberger <joerg@bec.de> [Fri, 28 Jun 2024 16:26:06 +0200] rev 51827
urllib2: redo response.readlines addition via class patching
Wed, 21 Aug 2024 22:15:05 -0400 typing: lock in new pytype gains from making revlog related classes typeable
Matt Harbison <matt_harbison@yahoo.com> [Wed, 21 Aug 2024 22:15:05 -0400] rev 51826
typing: lock in new pytype gains from making revlog related classes typeable These were pretty clean changes in the pyi files from earlier in this series, so add them to the code to make it more understandable. There's one more trivial hint that can be added to the return of `mercurial.revlogutils.rewrite._filelog_from_filename()`, however it needs to be imported from '..' under the conditional of `typing.TYPE_CHECKING`, and that seems to confuse the import checker- possibly because there's already an import block from that level. (I would have expected a message about multiple import statements in this case, but got one about higher level imports should come first, no matter where I put the import statement.)
Tue, 20 Aug 2024 00:07:05 -0400 typing: add types to `revlog.revlogproblem`
Matt Harbison <matt_harbison@yahoo.com> [Tue, 20 Aug 2024 00:07:05 -0400] rev 51825
typing: add types to `revlog.revlogproblem` These attrs showed as `Any` after the previous commit made the class visible to pytype.
Mon, 19 Aug 2024 22:46:09 -0400 typing: make the revlog classes known to pytype
Matt Harbison <matt_harbison@yahoo.com> [Mon, 19 Aug 2024 22:46:09 -0400] rev 51824
typing: make the revlog classes known to pytype These are the same changes as c1d7ac70980b and 45270e286bdc made to dirstate, for the same reasons.
Mon, 19 Aug 2024 22:27:43 -0400 typing: make the manifest classes known to pytype
Matt Harbison <matt_harbison@yahoo.com> [Mon, 19 Aug 2024 22:27:43 -0400] rev 51823
typing: make the manifest classes known to pytype These are the same changes as c1d7ac70980b and 45270e286bdc made to dirstate, for the same reasons. The migration away from decorating the classes with `@interfaceutil.implementer` was started back in 3e9a660b074a, but missed one.
Mon, 19 Aug 2024 22:21:16 -0400 typing: make the filelog class known to pytype
Matt Harbison <matt_harbison@yahoo.com> [Mon, 19 Aug 2024 22:21:16 -0400] rev 51822
typing: make the filelog class known to pytype These are the same changes as c1d7ac70980b and 45270e286bdc made to dirstate, for the same reasons.
Wed, 21 Aug 2024 17:41:57 -0400 remotefilelog: adapt the `debugindex` command to past API changes
Matt Harbison <matt_harbison@yahoo.com> [Wed, 21 Aug 2024 17:41:57 -0400] rev 51821
remotefilelog: adapt the `debugindex` command to past API changes Pytype was missing these problems because it's currently inferring the classes for `filelog` and `revlog` to be `Any`. When that's fixed, these were flagged, so fix these first. The `filelog` class used to subclass `revlog`, but that was changed back in 1541e1a8e87d (with most or all of the "lost" attributes being forwarded to the embedded `revlog` attribute at that time). These forwarded references were dropped over time, and this command has been broken at least as far back as 68282a7b29a7 when the `version` field was dropped. Most of the fixes were as simple as calling the accessor for the embedded `revlog` member, but the general delta feature detection was a bit more involved- I copied the detection for it from `mercurial.revlogutils.debug.debug_revlog()`.
Wed, 21 Aug 2024 16:13:14 -0400 typing: add type hints to the `opener` attributes and arguments of revlog
Matt Harbison <matt_harbison@yahoo.com> [Wed, 21 Aug 2024 16:13:14 -0400] rev 51820
typing: add type hints to the `opener` attributes and arguments of revlog When making revlog and filelog classes visible to pytype, it got confused quite a bit in `mercurial/revlogutils/rewrite.py`, thinking it had a plain `Callable`, and flagging additional methods on it like `join()` and `rename()`. I couldn't figure out how it reduced to that (and PyCharm flagged `opener` references as `Any`), but this makes it happy. So make this change before making the classes visible. The vfs class hierarchy is a bit wonky (e.g. `filteredvfs` is not a `vfs`), so this may need to be revisited with a Protocol class that covers all of the `vfs` classes. But for now, everything works.
Wed, 21 Aug 2024 16:09:22 -0400 remotefilelog: honor the `--format` arg of the `debugindex` command
Matt Harbison <matt_harbison@yahoo.com> [Wed, 21 Aug 2024 16:09:22 -0400] rev 51819
remotefilelog: honor the `--format` arg of the `debugindex` command Flagged by PyCharm while investigating pytype spew. The other `**opts` above are already accessed as str. I've never used remotefilelog, and don't have a repo to test this on, so I'm trusting the nearby code.
Wed, 07 Aug 2024 22:05:36 +0200 merge: sort filemap only if requested by the caller stable
Manuel Jacob <me@manueljacob.de> [Wed, 07 Aug 2024 22:05:36 +0200] rev 51818
merge: sort filemap only if requested by the caller The name `sorted` refers to a built-in function, which is always true, so the else branch of this if statement was dead code. Because, with this fix, the function can iterate over the dict items while yielding values, the dict should not change size while the generator is running. Because of that, it is required to re-introduce code that makes a caller copy the filemap before modification, which was removed in 3c783ff08d40cbaf36eb27ffe1d296718c0f1d77 (that changeset also introduced the filemap() method including the bug that’s being fixed by this changeset).
Tue, 20 Aug 2024 22:47:11 -0400 shelve: consistently convert exception to bytes via `stringutil.forcebytestr`
Matt Harbison <matt_harbison@yahoo.com> [Tue, 20 Aug 2024 22:47:11 -0400] rev 51817
shelve: consistently convert exception to bytes via `stringutil.forcebytestr` The other two places in this module use this, and past experience shows that this method does a nicer job. I'm not sure why we're converting to bytes here- `KeyError` is built-in and will have str attrs, and `RepoLookupError` is a subclass of the built-in `Exception` class (not `errors.Error`, which is allegedly the baseclass for all Mercurial exceptions).
Tue, 20 Aug 2024 22:34:51 -0400 typing: add type hints to `mercurial.shelve`
Matt Harbison <matt_harbison@yahoo.com> [Tue, 20 Aug 2024 22:34:51 -0400] rev 51816
typing: add type hints to `mercurial.shelve` Pytype wasn't flagging anything here yet, but PyCharm was really unhappy about the usage of `state` objects being passed to various methods that accessed attrs on it, without any obvious attrs on the class because there's no contructor. Filling that out made PyCharm happy, and a few other things needed to be filled in to make that easier, so I made a pass over the whole file and filled in the trivial hints. The other repo, ui, context, matcher, and pats items can be filled in after the context and match modules are typed.
Tue, 20 Aug 2024 18:30:47 -0400 typing: lock in correct changes from pytype 2023.04.11 -> 2023.06.16
Matt Harbison <matt_harbison@yahoo.com> [Tue, 20 Aug 2024 18:30:47 -0400] rev 51815
typing: lock in correct changes from pytype 2023.04.11 -> 2023.06.16 There were a handful of other changes to the pyi files generated when updating pytype locally (and jumping from python 3.8.0 to python 3.10.11), but they were not as clear (e.g. the embedded type in a list changing from `nothing` to `Any` or similar). These looked obviously correct, and agreed with PyCharm's thoughts on the signatures. Oddly, even though pytype starting inferring `obsutil._getfilteredreason()` as returning bytes, it (correctly) complained about the None path when it was typed that way. Instead, raise a ProgrammingError if an unhandled fate is calculated. (Currently, all possibilities are handled, so this isn't reachable unless another fate is added in the future.)
Tue, 20 Aug 2024 17:46:17 -0400 monotone: replace %s interpolation with appropriate numeric specifiers
Matt Harbison <matt_harbison@yahoo.com> [Tue, 20 Aug 2024 17:46:17 -0400] rev 51814
monotone: replace %s interpolation with appropriate numeric specifiers The length is an int, and the version is a float. Neither work with bytes on py3. This was noticed when looking at nearby code after updating pytype changed some signatures.
Tue, 20 Aug 2024 16:32:13 -0400 shelve: raise an error when loading a corrupt state file in an impossible case
Matt Harbison <matt_harbison@yahoo.com> [Tue, 20 Aug 2024 16:32:13 -0400] rev 51813
shelve: raise an error when loading a corrupt state file in an impossible case The old return statement was flagged by pytype 2023.06.16 running under python 3.10.11. No idea why it isn't caught in CI running the same pytype with py3.7. This function is only called by `unshelvecmd()` (which first checks that either `--abort` or `--continue` is specified), and `hgabortunshelve()` and `hgcontinueunshelve()`, which locally apply `--abort` or `--continue` respectively. Therefore, there is no other way to call this, and this error should never be seen, but pytype can't figure that out on its own. Given that the abort case clears the state, it seems reasonable to defensively code this and not make that a blanket `else` case, on the off chance a 3rd way of calling this appears in the future.
Tue, 20 Aug 2024 11:18:10 -0400 contrib: print the version of pytype used to do the type checking
Matt Harbison <matt_harbison@yahoo.com> [Tue, 20 Aug 2024 11:18:10 -0400] rev 51812
contrib: print the version of pytype used to do the type checking This will help with CI. I don't see a way to print the version of python that's running it. When I tried `head -n 1 $(which pytype)`, the CI run printed: #!/usr/bin/env bash Locally, that gives the path to the python interpreter in the venv, so IDK what's different.
Sat, 17 Aug 2024 18:43:23 -0400 typing: create an @overload of `phasecache` ctor to handle the copy case
Matt Harbison <matt_harbison@yahoo.com> [Sat, 17 Aug 2024 18:43:23 -0400] rev 51811
typing: create an @overload of `phasecache` ctor to handle the copy case In `phasecache.copy()`, it calls `self.__class__(None, None, _load=False)`, but the constuctor is typed to take a non-None repository. For the `_load=False` case, all args are ignored (and the copy function itself populates the attrs on the new object), so this isn't an error. For the default `_load=True` case, it needs a non-None repository. This is the simplest way to handle that duality. The reason this wasn't being detected is because pytype is confused by the interface decorators on the `localrepository` class, and is inferring the whole class as `Any`. (See 3e9a660b074a or c1d7ac70980b) Therefore, the type hint of `localrepo.localrepository` here was also effectively `Any`, which disabled the type checking entirely. This is the first foray into using `typing_extensions` to unlock future typing features. I think this is safe and reasonable because 1) it is only imported in the type checking phase (so no need to vendor our own copy), and 2) pytype has its own copy of `typing_extensions` bundled with it, so no need to alter the test environment. When run with a version of python that supports the symbol(s) natively, `typing_extensions` simply re-exports from `typing`, so there shouldn't be any future headaches with this.
Sat, 17 Aug 2024 17:38:35 -0400 typing: declare the `_phasesets` member of `phasecache` to be `Optional`
Matt Harbison <matt_harbison@yahoo.com> [Sat, 17 Aug 2024 17:38:35 -0400] rev 51810
typing: declare the `_phasesets` member of `phasecache` to be `Optional` Something in this area got flagged while making the repository class visible to pytype (instead of being typed as `Any`). A None assignment to something not optional is wrong, and when I tried setting it to `{}` to keep it non-Optional, some tests failed. There are checks for the attr being None elsewhere, so this seems to have just been an oversight.
Fri, 16 Aug 2024 18:11:52 -0400 typing: hide the interface version of `dirstate` during type checking
Matt Harbison <matt_harbison@yahoo.com> [Fri, 16 Aug 2024 18:11:52 -0400] rev 51809
typing: hide the interface version of `dirstate` during type checking As noted in the previous commit, the `dirstate` type is still inferred as `Any` by pytype, including where it is used as a base class for the largefiles dirstate. That effectively disables most type checking. The problems fixed two commits ago were flagged by this change. I'm not at all clear what the benefit of the original type is, but that was what was used at runtime, so I don't want to change the largefiles base class to the raw class. Having both a lowercase and camelcase name for the same thing isn't great, but given that this trivially finds problems without worrying about which symbol clients may be using, and the non-raw type is useless to pytype anyway, I'm not going to worry about it.
Fri, 16 Aug 2024 18:02:32 -0400 dirstate: remove the interface decorator to help pytype
Matt Harbison <matt_harbison@yahoo.com> [Fri, 16 Aug 2024 18:02:32 -0400] rev 51808
dirstate: remove the interface decorator to help pytype This is the same change that was made for some of the manifest classes in 3e9a660b074a. Note that `dirstate` is still inferred as `Any`, but at least we have `DirState` with all of the expected attributes.
Fri, 16 Aug 2024 17:58:17 -0400 largefiles: sync up `largefilesdirstate` methods with `dirstate` base class
Matt Harbison <matt_harbison@yahoo.com> [Fri, 16 Aug 2024 17:58:17 -0400] rev 51807
largefiles: sync up `largefilesdirstate` methods with `dirstate` base class As it currently stands, pytype infers the `dirstate` class (and anything else decorated with `@interfaceutil.implementer`) as `Any`. When that is worked around, it suddenly noticed that most of these methods don't exist in the `dirstate` class anymore. Since they only called into the missing methods and there's no test failures, we can assume these are never called, and they can be dropped. In addition, PyCharm flagged `set_tracked()` and `_ignore()` as not overriding a superclass method with the same arguments. The missing default parameter for the former was the obvious issue. I'm guessing that the latter was named wrong because while there is `_ignore()` in the base class, it takes no arguments and returns a matcher. The `_ignorefiles()` superclass method also takes no args, and returns a list of bytes. The `_ignorefileandline()` superclass method DOES take a file, but returns a tuple. Therefore, the closest match is `_dirignore()`, which takes a file AND returns a bool. No idea why this needs to be overridden though.
Fri, 16 Aug 2024 11:12:19 +0100 sparse: reliably avoid writing to store without a lock
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 16 Aug 2024 11:12:19 +0100] rev 51806
sparse: reliably avoid writing to store without a lock With the code as written before this patch we can still end up writing to store in `debugsparse`. Obviously we'll write to it if by accident a store requirement is modified, but more importantly we write to it if another concurrent transaction modifies the requirements file on disk. We can't rule this out since we're not holding the store lock, so it's better to explicitly pass a permission to write instead of inferring it based on file contents.
Thu, 15 Aug 2024 13:52:14 +0100 debugsparse: stop taking the store lock
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 15 Aug 2024 13:52:14 +0100] rev 51805
debugsparse: stop taking the store lock debugsparse is a workspace-only opperation, or it better be workspace-only. Let's make it to stop taking the store lock.
Thu, 15 Aug 2024 14:54:22 +0100 scmutils: read the requires file before writing to avoid unnecessary rewrite
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 15 Aug 2024 14:54:22 +0100] rev 51804
scmutils: read the requires file before writing to avoid unnecessary rewrite This lets us get away without the repo lock in situations where we need to write requirements, but we know we're not changing the store requirements.
Thu, 15 Aug 2024 14:56:50 +0100 localrepo: remove _readrequires function in favor of scmutil.readrequires
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 15 Aug 2024 14:56:50 +0100] rev 51803
localrepo: remove _readrequires function in favor of scmutil.readrequires
Thu, 15 Aug 2024 14:53:17 +0100 scmutil: add `readrequires` next to `writerequires`
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 15 Aug 2024 14:53:17 +0100] rev 51802
scmutil: add `readrequires` next to `writerequires` The code is copied from localrepo.py.
Wed, 14 Aug 2024 03:25:16 -0400 typing: correct a type hint in `mercurial.manifest`
Matt Harbison <matt_harbison@yahoo.com> [Wed, 14 Aug 2024 03:25:16 -0400] rev 51801
typing: correct a type hint in `mercurial.manifest` Obvious typo that was flagged by PyCharm.
Sat, 10 Aug 2024 14:22:26 -0400 typing: add hints to `mercurial.util.mktempcopy()`
Matt Harbison <matt_harbison@yahoo.com> [Sat, 10 Aug 2024 14:22:26 -0400] rev 51800
typing: add hints to `mercurial.util.mktempcopy()` Might as well, now that the previous commit indicated what types are required.
Sat, 10 Aug 2024 14:18:44 -0400 typing: fix the hint for the `mode` argument of `platform.copymode()`
Matt Harbison <matt_harbison@yahoo.com> [Sat, 10 Aug 2024 14:18:44 -0400] rev 51799
typing: fix the hint for the `mode` argument of `platform.copymode()` The posix module is doing a bitwise AND with this and an integer, so it can't be bytes. The only caller that provides the argument is `util.mktempcopy()`, and pytype infers the type as Any, which explains why this wasn't caught.
Fri, 09 Aug 2024 22:45:32 +0200 largefiles: fix check that ensures that --all-largefiles is only used locally stable
Manuel Jacob <me@manueljacob.de> [Fri, 09 Aug 2024 22:45:32 +0200] rev 51798
largefiles: fix check that ensures that --all-largefiles is only used locally Previously, the command added in the test failed with “abort: --all-largefiles is incompatible with non-local destination existing_destination”. The reason for the buggy behavior was the use of hg.islocal(), which does “return true if repo (or path pointing to repo) is local” and, for local paths, assumes that the path is actually pointing to an existing repository and returns whether the path is not a regular file (in which case it assumes that it is a bundlerepo, which are considered non-local).
Fri, 05 May 2023 06:08:36 -0600 exchange: trivial simplification
Felipe Contreras <felipe.contreras@gmail.com> [Fri, 05 May 2023 06:08:36 -0600] rev 51797
exchange: trivial simplification Both sides of the condition do essentially the same thing, except one with fastpath=True. No functional changes.
Fri, 09 Aug 2024 14:26:13 +0200 import: fix erroneous comparison of str with bytes stable
Manuel Jacob <me@manueljacob.de> [Fri, 09 Aug 2024 14:26:13 +0200] rev 51796
import: fix erroneous comparison of str with bytes
Thu, 08 Aug 2024 17:28:38 +0400 histedit: create state and acquire locks earlier stable
Anton Shestakov <av6@dwimlabs.net> [Thu, 08 Aug 2024 17:28:38 +0400] rev 51795
histedit: create state and acquire locks earlier This makes chistedit (histedit with curses UI) not write any files inside repo without wlock. It also makes sense to wrap the entire process of preparing commands inside the curses UI inside locks because we don't want anything else to touch wdir or repo during this time.
Tue, 06 Aug 2024 22:51:41 +0200 py3: use str literal instead of bytes literal stable
Manuel Jacob <me@manueljacob.de> [Tue, 06 Aug 2024 22:51:41 +0200] rev 51794
py3: use str literal instead of bytes literal
Tue, 06 Aug 2024 18:23:59 +0200 typing: fix type annotation stable
Manuel Jacob <me@manueljacob.de> [Tue, 06 Aug 2024 18:23:59 +0200] rev 51793
typing: fix type annotation
Tue, 06 Aug 2024 17:53:59 +0200 cffi: pass bytes instead of str to ffi.new("char[]", …) stable
Manuel Jacob <me@manueljacob.de> [Tue, 06 Aug 2024 17:53:59 +0200] rev 51792
cffi: pass bytes instead of str to ffi.new("char[]", …) The type annotations seem to imply that the passed values are always already bytes, but they aren’t necessarily. Before Python 3.11, the documentation stated that bytes can be used to annotate arguments whose type is actually any of bytes, bytearray, or memoryview.
Mon, 05 Aug 2024 21:21:32 +0200 cffi: call bytes() instead of str() on CFFI buffer instances stable
Manuel Jacob <me@manueljacob.de> [Mon, 05 Aug 2024 21:21:32 +0200] rev 51791
cffi: call bytes() instead of str() on CFFI buffer instances
Mon, 05 Aug 2024 21:08:36 +0200 cffi: pass C type and attribute names as str instead of bytes stable
Manuel Jacob <me@manueljacob.de> [Mon, 05 Aug 2024 21:08:36 +0200] rev 51790
cffi: pass C type and attribute names as str instead of bytes
Mon, 05 Aug 2024 20:47:17 +0200 py3: fix type of some elements of __all__ lists stable
Manuel Jacob <me@manueljacob.de> [Mon, 05 Aug 2024 20:47:17 +0200] rev 51789
py3: fix type of some elements of __all__ lists
Mon, 05 Aug 2024 20:08:23 +0200 manifest: deprecated readdelta and readfast
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 05 Aug 2024 20:08:23 +0200] rev 51788
manifest: deprecated readdelta and readfast These method should not have any user left.
(0) -30000 -10000 -3000 -1000 -300 -100 -60 +60 +100 +300 tip