[PATCH 18 of 18 "] verify: also check full manifest validity during verify runs [RFC]

[Pulkit Goyal]

On Wed, Mar 6, 2019 at 8:10 PM Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

> # HG changeset patch
> # User Pierre-Yves David <pierre-yves.david at octobus.net>
> # Date 1551881213 -3600
> #      Wed Mar 06 15:06:53 2019 +0100
> # Node ID 1e978412397a4fe629dfa9420b1a7773dc936b19
> # Parent  92091b3de1503bf562fe5bf2b544781f92702738
> # EXP-Topic verify
> # Available At https://bitbucket.org/octobus/mercurial-devel/
> #              hg pull https://bitbucket.org/octobus/mercurial-devel/ -r
> 1e978412397a
> verify: also check full manifest validity during verify runs [RFC]
>
> Before this changes, `hg verify` only checked if a manifest revision
> existed and
> referenced the proper files. However it never checked the manifest revision
> content itself.
>
> Mercurial is expecting manifest entries to be sorted and will crash
> otherwise.
> Since `hg verify` did not tried a full restoration of manifest entry, it
> could
> ignore this kind of corruption.
>
> This new check significantly increases the cost of a `hg verify` run. This
> especially affects large repository not using `sparse-revlog`. We might
> want to
> put it behind a new flag like `--full`. Another way to look at this would
> be to
> offer a `--quick` flag that disable it. In particular, since `hg recover`
> runs
> verify, this could impact users.
>

A slow `hg recover` is already painful for us whenever we run it. So we
decided whatever happen, we will never Ctrl+C a hg process.

That said, what are the cases which can lead to unsorted manifest
revisions? It will be worth putting them in commit message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190306/2d498594/attachment.html>