- Oct 24, 2024
-
-
Pierre Augier authored
-
- Nov 23, 2024
-
-
Pierre Augier authored
-
- Oct 24, 2024
-
-
Pierre Augier authored
-
- Nov 23, 2024
-
-
Pierre Augier authored
-
- Oct 24, 2024
-
-
Pierre Augier authored
-
- Nov 23, 2024
-
-
Pierre Augier authored
-
- Oct 23, 2024
-
-
Pierre Augier authored
This is redundant with requires-python in pyproject.toml.
-
Pierre Augier authored
-
- Oct 21, 2024
-
-
Pierre Augier authored
-
- Nov 21, 2024
-
-
Matt Harbison authored
Before it was optional, and either 1.1 or 1.2 was sufficient. Now that the default minimum is 1.2, it needs to be present to work out of the box. The code here is more convoluted than the corresponding checks in `sslutil.py`, but I'm leaving it alone because it can all be simplified when py38 is dropped.
-
Matt Harbison authored
Simple enough, and then we don't need comments to cross-reference other areas of code that need to be kept in sync. Since the `_getreplacements()` list is now partially dynamically generated and needed to change anyway, also move the one line that was being appended separately to the list for some reason, for clarity.
-
- Nov 18, 2024
-
-
Dan Villiom Podlaski Christiansen authored
-
- Nov 04, 2024
-
-
Raphaël Gomès authored
It is fully replaced with the now stable `std::io::IsTerminal` trait. This was the last dependency flagged as a warning by `cargo audit`, aside from `cpython` which we know about all too well: the plan is to transition to PyO3 soon-ish.
-
Raphaël Gomès authored
Aside from being more up-to-date in general, this makes its own dependency on the unmaintained and now useless `atty` disappear.
-
Raphaël Gomès authored
This brings in more up-to-date dependencies, some bug fixes (none of which are relevant yet), and slightly improved compile times.
-
Raphaël Gomès authored
It makes sense to keep our doc build happy, even if it is lacking.
-
Raphaël Gomès authored
All compressors should be `Send`, might as well make any future use easier.
-
Raphaël Gomès authored
The `compress` function is unlikely to be used in highly contended situations, and creating a compressor has some overhead, on top of losing out on some potential advantages of longer-running optimizations from the compressor.
-
Raphaël Gomès authored
This only muddies the lib and makes the imports more confusing.
-
Raphaël Gomès authored
This is where it belongs
-
Raphaël Gomès authored
That's where they belong and should always have been there.
-
Raphaël Gomès authored
This was done very early in the Rust project's lifecycle and I had very little Rust experience. Let's keep the `DirstateParents` since they'll pop up in all higher-level code and make the rest more explicit imports to make the imports less confusing and the lib less cluttered.
-
Raphaël Gomès authored
This makes the crate's imports confusing and muddies the discovery of the code.
-
Raphaël Gomès authored
The historical reasonning for `dirstate_tree` existing in the first place is that a new approach was needed for the tree-like dirstate and it was easier to start somewhat fresh. Now that the former dirstate is (long) gone, we can merge those two modules to avoid the confusion that even the module creators sometimes get.
-
Raphaël Gomès authored
This is more explicit.
-
Raphaël Gomès authored
This is more explicit.
-
Raphaël Gomès authored
This is more explicit and will not be confused with `len`.
-
- Oct 29, 2024
-
-
Raphaël Gomès authored
`open` being read *and* write is surprising because it differs from the Rust stdlib where `std::fs::File::open` is read-only by default. More importantly, writing is more dangerous than reading, so let's make it more explicit.
-
Raphaël Gomès authored
This was the warning by clippy 1.82.0, which explains the change: ``` warning: this function depends on never type fallback being `()` --> hg-core/src/dirstate_tree/status.rs:397:5 | 397 | / fn traverse_fs_directory_and_dirstate<'ancestor>( 398 | | &self, 399 | | has_ignored_ancestor: &'ancestor HasIgnoredAncestor<'ancestor>, 400 | | dirstate_nodes: ChildNodesRef<'tree, 'on_disk>, ... | 404 | | is_at_repo_root: bool, 405 | | ) -> Result<bool, DirstateV2ParseError> { | |___________________________________________^ | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #123748 <https://github.com/rust-lang/rust/issues/123748> = help: specify the types explicitly note: in edition 2024, the requirement `!: rayon::iter::FromParallelIterator<()>` will fail --> hg-core/src/dirstate_tree/status.rs:453:28 | 453 | .collect::<Result<_, _>>()?; | ^^^^^^^^^^^^ = note: `#[warn(dependency_on_unit_never_type_fallback)]` on by default ```
-
Raphaël Gomès authored
This test wasn't testing anything anymore since the feature has been removed. This was caught by clippy 1.82.0.
-
Raphaël Gomès authored
These were highlighted by the latest version of clippy (1.82.0).
-
Raphaël Gomès authored
This normalizes the naming scheme between the `Revlog`, `Changelog`, etc. which is less suprising, though no real bugs could stem from this because of the type signature mismatch. The very high-level `Repo` object still uses an `UncheckedRevision` parameter for its methods because that's what most callers will want.
-
- Nov 12, 2024
-
-
Pierre-Yves David authored
We have over ten thousands old pipeline that take a huge space and that I suspect to be the source of some slowdown in merge request. However it seems that the only way to clear them is manually and through the API, so lets do it. The script was run today.
-
Matt Harbison authored
TLS v1.0 and v1.1 are deprecated by RFC8996[1]: These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018)... Various browsers have disabled or removed it[2][3][4], as have various internet services, and Windows 11 has it disabled by default[5]. We should move on too. (We should also bump it on the server side, as this config only affects clients not allowing a server to negotiate down. But the only server-side config is a `devel` option to pick exactly one protocol version and is commented as a footgun, so I'm hesitant to touch that. See 7dec5e441bf7 for details, which states that using `hg serve` directly isn't expected for a web service.) I'm not knowledgeable enough in this area to know if we should follow up with disabling certain ciphers too. But this should provide better security on its own. [1] https://datatracker.ietf.org/doc/rfc8996/ [2] https://learn.microsoft.com/en-us/DeployEdge/microsoft-edge-policies#sslversionmin [3] https://hacks.mozilla.org/2020/02/its-the-boot-for-tls-1-0-and-tls-1-1/ [4] https://security.googleblog.com/2018/10/modernizing-transport-security.html [5] https://techcommunity.microsoft.com/blog/windows-itpro-blog/tls-1-0-and-tls-1-1-soon-to-be-disabled-in-windows/3887947
-
- Nov 11, 2024
-
-
Matt Harbison authored
Two issues here: 1) We're well past Pythons that only support TLSv1.0 (py27 supports v1.2) 2) It never occurred to me that this is a client-only setting
-
Matt Harbison authored
This is easier to manage, and avoids one nested conditional. There is one final sweep of killing individual servers near the end, but that's left alone because there's a comment about not killing `tinyproxy.py`, due to potentially emitting additional output.
-
- Dec 22, 2020
-
-
Matt Harbison authored
AFAICT, all of the TLS versions are supported by the server without doing any explicit work, and there's only a `devel` config to specify an exact version on the server side. Clients would also use TLSv1.3 if available, but this prevents the server from negotiating down. This also causes "tls1.3" to be listed in `hg debuginstall`, even though it was previously supported (if the Python intepreter supported it- IDK if there's a good way to proactively test for and show future protocols without requiring manual updates like this). The v1.3 tests are nested inside the v1.2 tests for simplicity. The v1.2 blocks already assume v1.0 and v1.1 support, so this seems reasonable for now. If/when the older protocols start getting dropped, this will have to be reworked anyway.
-
- Dec 21, 2020
-
-
Matt Harbison authored
I want to add tls1.3 support, and test-https.t already uses the existing ports to test tls1.0 through 1.2. It doesn't look to me like it can easily be converted to a bunch of #testcases, because this also tests downgrades to prior versions for the given client version. This partially reverts bc010fcd836b.
-
- Nov 11, 2024
-
-
Matt Harbison authored
The last usage was removed in 94cf83d9a2c9.
-
- Nov 20, 2024
-
-
Matt Harbison authored
-