Georges Racinet <georges.racinet@octobus.net> [Thu, 30 Mar 2023 12:21:38 +0200] rev 50414
rust-changelog: introduce ChangelogEntry parent entries accessors
Straightforwards now that lifetimes are explicit in `RevlogEntry`
parent accessors.
Georges Racinet <georges.racinet@octobus.net> [Thu, 30 Mar 2023 12:20:53 +0200] rev 50413
rust-revlog: fix lifetime problem for RevlogEntry parent entries accessors
Without this, the lifetime of the result is equated to the lifetime of the
`self` reference, preventing callers, e.g., to take a `RevlogEntry` and
return its `p1_entry()`, as it looks like returning something that does not
outlive the *reference to* the `RevlogEntry`.
Georges Racinet <georges.racinet@octobus.net> [Thu, 30 Mar 2023 12:14:57 +0200] rev 50412
rust-revlog: explicit naming for `RevlogEntry` lifetime
This matches what has been done in `revlog::changelog::ChangelogRevisionData`,
and has the advantage of making things clearer when we introduce other, shorter
lived lifetimes.
Georges Racinet <georges.racinet@octobus.net> [Wed, 29 Mar 2023 20:50:42 +0200] rev 50411
rust-changelog: introducing an intermediate `ChangelogEntry`
Before this change, client code needing to extract, e.g, the Node ID and the
description from a changeset had no other choice than calling both
`entry_for_rev()` and `data_for_rev()`. This duplicates some (limited) computation, and
more importantly imposes bad hygiene for client code: at some point of developement,
the client code would have to pass over both entry and data in its internal layers,
which at some point of development would raise the question whether they are consistent.
We introduce the intermediate `ChangelogEntry` from which both conversion to the generic
`RevlogEntry` and extraction of `ChangelogRevisionData` are possible.
It might grow some convenience methods in the future.
We keep the `data_for_rev()` method of `Changelog` for compatibility, pointing users at the more
powerful alternative.