[PATCH 3 of 6] repoview: simplify process in _getstatichidden

Durham Goode durham at fb.com
Fri Apr 3 18:07:53 CDT 2015



On 4/3/15 3:23 PM, Pierre-Yves David wrote:
> # HG changeset patch
> # User Pierre-Yves David <pierre-yves.david at fb.com>
> # Date 1428096953 25200
> #      Fri Apr 03 14:35:53 2015 -0700
> # Node ID 52464cbacdf048fa115caa7109baff6f2631211c
> # Parent  ce977bd09297ff9320b60c3ed2ec45ba1103d147
> repoview: simplify process in _getstatichidden
>
> Since all children are processed before they parents we can apply the following algorithm:
>
> For each revs (descending order):
>
> * If I'm still hidden, no children will blocking me,
> * If I'm not hidden, I must remove my parent from the hidden set,
>
> This allow use to dynamically change the set of 'hidden' revision, dropping the
> need for the 'actuallyhidden' dictionnary and 'blocked' boolean in the queue.
>
> As before, we start iterating from all heads and stop at the first public
> changesets. This ensure the hidden computation is 'O(not public())' instead of
> 'O(len(min(not public()):))'.
>
> diff --git a/mercurial/repoview.py b/mercurial/repoview.py
> --- a/mercurial/repoview.py
> +++ b/mercurial/repoview.py
> @@ -30,39 +30,34 @@ def _getstatichidden(repo):
>       while keeping the graph consistent.
>   
>       A second pass will be done to apply "dynamic blocker" like bookmarks or
>       working directory parents."""
>       assert not repo.changelog.filteredrevs
> -    hideable = hideablerevs(repo)
> -    if hideable:
> -        actuallyhidden = {}
> +    hidden = set(hideablerevs(repo))
It doesn't matter right now, but we should start writing our algorithms 
such that they never require full knowledge of these kinds of sets 
(hidden, obsolete, etc).  For instance, in the future hideablerevs might 
become a lazily computed set (I have a patch that does it, but the perf 
impact is too low right now), and forcing it to become a set would 
defeat the purpose.  It's a mind set that will make these things more 
scalable later I think.


More information about the Mercurial-devel mailing list