delta-find: never do anything fancy when general delta is off
Without general delta, the only option is to do a delta against the previous
revision in the revlog, or to do a full snapshot. So no need to dive into the
more complicated logic.
This prevent Mercurial to misbehave when applying remote deltas when
`pulled-delta-reuse-policy` was set to "try-base" or "forced" and would produce
and store invalid deltas.
We add an associated tests to make sure this scenario is covered by tests.
There are more code to cleanup after this, but I what to keep the fixing patch
simple.
delta-find: assume the target-rev if not specified
This will be useful in the next patch, but I am putting it in its own commit to
make sure we can easily bisect any subtle side effect. (none are expected, but
still)
chg: set CHGHG before connecting to command server
cf4d2f31 (!523) changed chg to set `CHGHG` itself when spawning a new command
server, in order to ensure that the path to the `hg` executable would be checked
during server validation. (This is useful when chg is built with `HGPATHREL`).
However, that change broke chg because it failed to set `CHGHG` before trying
to connect to an existing command server. This means that if `CHGHG` is not
present in the environment, chg will always spawn a new command server, entirely
negating the point of chg.
This breakage wasn't initially caught because of the difficulty of writing
automated tests with the `HGPATHREL` feature enabled, which meant the change
was only tested manually to make sure that it fixed the problem with `HGPATHREL`
that prompted the change.
In practice, this functionality is only really useful when chg is built with
`HGPATHREL`, so I considered wrapping it in an `#ifdef` to preserve the old
behavior by default. However, this makes it hard to write tests since one would
have to explicitly set `HGPATHREL=1` when running `run-tests.py` (which is why
the original change lacked tests). It would be great if there were a way of
testing features that are gated behind conditional compilation.
Added signature for changeset
f952be90b051
Added tag 6.4.2 for changeset
f952be90b051
revlog-split: make sure the self._indexfile attribut is reset (
issue6811)
Before this change, after a transaction committing a file split, a revlog
object would have its `self._indexfile` attribute desynchronised from the
actual file storing the data. If that same object is reused (as we do for the
manifest during clone bundles), this lead to the data being writting in the
wrong location and the repository to go corrupt.
We not properly reset the attribut when applicable and everything is back in
working order.
revlog-split: also check a case where bundle contains multiple changegroup
This case is not affected, we remains in the same transaction. However it seems
important to improve the test coverage around these "features". It also helped
to assert the scop of the critical bug.
revlog-split: show manifest data loss situation when using clonebundle
After the commit of the transaction from applying the clone bundle, changes to
the manifest from the subsequent pull would write index data in the wrong file.
This lead to data being "lost" after the pull and the repository to be
corrupted. We add a test checking this specific scenario.
In practice, the issue only affects the manifest but we also test the issue with a file for future proofing things up.
See test documentation and failure for details.
Added signature for changeset
83ea6ce48b4f
Added tag 6.4.1 for changeset
83ea6ce48b4f
sslutil: set context security level for legacy tls testing (
issue6760)
Current versions of OpenSSL do not allow the use of TLS <1.2 when the
library's security level is >=1 (1 being the default on most distributions).
Setting the security level in addition to the minimum protocol is therefore
necessary for the legacy protocol tests.
This is done here ONLY when testing, when:
- explicitly setting the cipher string, or
- using the "--insecure" flag, or
- using the "devel.serverexactprotocol" testing option.
See: https://github.com/openssl/openssl/blob/master/NEWS.md#major-changes-between-openssl-30-and-openssl-310-14-mar-2023