[PATCH 2 of 4] verify: introduce a notion of "level"

Martin von Zweigbergk martinvonz at google.com
Wed Apr 17 09:32:39 EDT 2019


Heh, that's very much related to my comment on the V2 of this patch.

Pierre-Yves, have you considered sending patches via Phabricator? That
keeps comments on various versions of a patch together in one place.

On Wed, Apr 17, 2019, 06:18 Gregory Szorc <gregory.szorc at gmail.com> wrote:

>
>
> > On Apr 17, 2019, at 01:38, 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 1555456341 -7200
> > #      Wed Apr 17 01:12:21 2019 +0200
> > # Node ID 55bd98999c25b10e220477fd4cc446a7c9c1f8ca
> > # Parent  f233cb63bc077267d8571378350d9563cbabcf3d
> > # EXP-Topic verify
> > # Available At https://bitbucket.org/octobus/mercurial-devel/
> > #              hg pull https://bitbucket.org/octobus/mercurial-devel/
> -r 55bd98999c25
> > verify: introduce a notion of "level"
> >
> > Some checks are slower than others, to help the user to run the checks
> he needs,
> > we are about to introduce new flag to select faster vs deeper runs. This
> put
> > the scaffolding in place to do this.
>
> I’m in favor of customizing verify behavior: it is an overdue feature IMO.
>
> Experience tells me that shoehorning things into a numeric level will be
> fragile and won’t scale well. I’m wondering if we should introduce
> individual “feature flags” / arguments to control what is verified. That
> will make the code a bit cleaner and easier to separate IMO. If we want to
> map a number to a set of verify options, we can do that too.
>
> This idea is scope bloat. But something tells me we’ll regret the
> limitations of numeric levels in the future. I’d rather pass in a set of
> things to verify. This is also more extensible.
>
> >
> > diff --git a/mercurial/hg.py b/mercurial/hg.py
> > --- a/mercurial/hg.py
> > +++ b/mercurial/hg.py
> > @@ -1092,9 +1092,9 @@ def outgoing(ui, repo, dest, opts):
> >     recurse()
> >     return 0 # exit code is zero since we found outgoing changes
> >
> > -def verify(repo):
> > +def verify(repo, level=None):
> >     """verify the consistency of a repository"""
> > -    ret = verifymod.verify(repo)
> > +    ret = verifymod.verify(repo, level=level)
> >
> >     # Broken subrepo references in hidden csets don't seem worth
> worrying about,
> >     # since they can't be pushed/pulled, and --hidden can be used if
> they are a
> > diff --git a/mercurial/verify.py b/mercurial/verify.py
> > --- a/mercurial/verify.py
> > +++ b/mercurial/verify.py
> > @@ -22,9 +22,12 @@ from . import (
> >     util,
> > )
> >
> > -def verify(repo):
> > +VERIFY_DEFAULT = 0
> > +
> > +def verify(repo, level=None):
> >     with repo.lock():
> > -        return verifier(repo).verify()
> > +        v = verifier(repo, level)
> > +        return v.verify()
> >
> > def _normpath(f):
> >     # under hg < 2.4, convert didn't sanitize paths properly, so a
> > @@ -34,10 +37,13 @@ def _normpath(f):
> >     return f
> >
> > class verifier(object):
> > -    def __init__(self, repo):
> > +    def __init__(self, repo, level=None):
> >         self.repo = repo.unfiltered()
> >         self.ui = repo.ui
> >         self.match = repo.narrowmatch()
> > +        if level is None:
> > +            level = VERIFY_DEFAULT
> > +        self._level = level
> >         self.badrevs = set()
> >         self.errors = 0
> >         self.warnings = 0
> > _______________________________________________
> > Mercurial-devel mailing list
> > Mercurial-devel at mercurial-scm.org
> > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190417/2c4de035/attachment.html>


More information about the Mercurial-devel mailing list