Raphaël Gomès <rgomes@octobus.net> [Thu, 06 Jul 2023 16:04:36 +0200] rev 50750
Added signature for changeset 3ffc7209bbae
Raphaël Gomès <rgomes@octobus.net> [Thu, 06 Jul 2023 16:04:18 +0200] rev 50749
Added tag 6.5 for changeset 3ffc7209bbae
Raphaël Gomès <rgomes@octobus.net> [Thu, 06 Jul 2023 16:02:59 +0200] rev 50748
relnotes: add 6.5 final
Georges Racinet <georges.racinet@octobus.net> [Thu, 06 Jul 2023 11:58:24 +0200] rev 50747
rust-changelog: removed now useless early conditional for NULL_REVISION
Now that the underlying `RevlogEntry` returned for `NULL_REVISION` is
viable, it has become pointless to check NULL_REVISION several times,
even for performance: the check will be far more frequent than the benefit
of bailing earlier in the rare case where the requested revision is
`NULL_REVISION`.
This case is covered explicitly by the first assertion of
`test_data_from_rev_null`.
Georges Racinet <georges.racinet@octobus.net> [Thu, 06 Jul 2023 11:53:40 +0200] rev 50746
rust-revlog: fix RevlogEntry.data() for NULL_REVISION
Before this change, the pseudo-entry returned by `Revlog.get_entry` for
`NULL_REVISION` would trigger errors in application code using it.
For example, this fixes a crash spotted with changelog data
while implementing RHGitaly: `Changelog.data_for_rev(-1)` was already
returning the pseudo content as expected, e.g., for `hg log`, but
`Changelog.entry_for_rev(-1).data()` would still crash with
"corrupted revlog, hash check failed for revision -1". There is
an added test for this scenario.
Georges Racinet <georges.racinet@octobus.net> [Thu, 06 Jul 2023 11:43:26 +0200] rev 50745
rust-revlog: using constant in test
Always better
Georges Racinet <georges.racinet@octobus.net> [Thu, 30 Mar 2023 11:34:30 +0200] rev 50744
rust-revlog: fix incorrect results with NULL_NODE prefixes
In case a short hash is a prefix of `NULL_NODE`, the correct revision
number lookup is `NULL_REVISION` only if there is no match in the nodemap.
Indeed, if there is a single nodemap match, then it is an ambiguity with the
always matching `NULL_NODE`.
Before this change, using the Mercurial development repository as a testbed (it
has public changesets with node ID starting with `0005` and `0009`), this is
what `rhg` did (plain `hg` provided for reference)
```
$ rust/target/debug/rhg cat -r 000 README
README: no such file in rev 000000000000
$ hg cat -r 000 README
abort: ambiguous revision identifier: 000
```
Here is the expected output for `rhg` on ambiguous prefixes (again, before
this change):
```
$ rust/target/debug/rhg cat -r 0001 README
abort: ambiguous revision identifier: 0001
```
The test provided by 8c29af0f6d6e in `test-rhg.t` could become flaky with
this change, unless all hashes are fixed. We expect reviewers to be more
sure about that than we are.
Georges Racinet <georges.racinet@octobus.net> [Thu, 30 Mar 2023 10:29:29 +0200] rev 50743
rust-revlog: split out method for `rev_from_node` without persistent nodemap
This will make easier for the bug fix that is about to come.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 08 Jun 2023 00:03:54 -0400] rev 50742
win32mbcs: unbyteify some strings for py3 support
A crash was reported on the TortoiseHg bug tracker for this[1].
[1] https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5905
Raphaël Gomès <rgomes@octobus.net> [Tue, 04 Jul 2023 12:30:31 +0200] rev 50741
heptapod-ci: turn off pipelines for merge request events
These are always duplicated by the external (from the user) push, or internal
(from Heptapod itself) push pipeline, so they're entirely redundant.