After this patch, filterrevs() can take an optional argument
visibilityexceptions which is a set of revs which should be exception to
being hidden. The visibilityexceptions will be passed to the function computing
hidden revisions for that filtername and are considered there while calculating
the set of hidden revs.
Details
- Reviewers
yuja - Group Reviewers
hg-reviewers - Commits
- rHG3c9c05a38d78: repoview: add visibilityexception argument to filterrevs() and related fns
Diff Detail
- Repository
- rHG Mercurial
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
mercurial/repoview.py | ||
---|---|---|
160 | Since revisions are dynamically unhidden, we can't cache the result Perhaps we could apply visibilityexceptions at repoview.changelog(). revs = filterrevs(unfi, self.filtername) revs = revs - self._visibilityexceptions |
Since revisions are dynamically unhidden, we can't cache the result
to the (unfiltered) repo per filterename.
FWIW, if the cache don't include "unhidden" revisions, maybe we don't
need new filter names like 'visible-hidden"?
Yep I agree, but I wanted be on the safe side to prevent unknown bugs by using the same filtername.
mercurial/repoview.py | ||
---|---|---|
160 | One reason to have this considered in computehidden() is we want this to be considered in _revealancestors() otherwise things which needs parent of hidden revision will throw an error like export. I will make it not cache the result if visibilityexceptions is present. |
FWIW, if the cache don't include "unhidden" revisions, maybe we don't
need new filter names like 'visible-hidden"?Yep I agree, but I wanted be on the safe side to prevent unknown bugs by using the same filtername.
Actually we have to use new filtername to separate branch/tags caches until
we can disable these caches when revisions are dynamically pinned.
Queued the series, thanks.
Since revisions are dynamically unhidden, we can't cache the result
to the (unfiltered) repo per filterename.
Perhaps we could apply visibilityexceptions at repoview.changelog().