[PATCH 18 of 18 "] verify: also check full manifest validity during verify runs [RFC]
7895pulkit at gmail.com
Wed Mar 6 13:31:13 EST 2019
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
> 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
> Since `hg verify` did not tried a full restoration of manifest entry, it
> 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`
> 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...
More information about the Mercurial-devel