[PATCH 2 of 4] phases: add an internal phases

[Yuya Nishihara]

On Mon, 27 Aug 2018 12:39:54 +0200, Boris Feld wrote:
> # HG changeset patch
> # User Boris Feld <boris.feld at octobus.net>
> # Date 1535152788 -7200
> #      Sat Aug 25 01:19:48 2018 +0200
> # Node ID de8fadb2459129a8ee097d2a8cadb23ee02473c7
> # Parent  1a32c924756abb3794e81d3fa19136939d83d5e5
> # EXP-Topic internal-phase.new-phase
> # Available At https://bitbucket.org/octobus/mercurial-devel/
> #              hg pull https://bitbucket.org/octobus/mercurial-devel/ -r de8fadb24591
> phases: add an internal phases
> 
> The phase is meant to be used for internal commit that are a byproduct of
> command operation (eg:shelve).
> 
> This changeset focus on getting the most important feature in, more advanced
> API is to be introduced in later changesets.
> 
> The phase approach to handle internal has multiple advantages:
> * simple to implement, reuse optimized code,
> * fits well with existing phases. We don't want internal changeset to be
>   exchanged or served.
> * easy to extend to for lifecycle handling.
> 
> More thinking about internal changeset at https://www.mercurial-scm.org/wiki/InternalsPlan
> 
> We add this new phases with a high number to leave some room to possible other
> phases. We also try out playing with the idea of "flag" for phases, each flag
> would convey a distinct meaning. We can drop the flag idea in the future
> (keeping the existing numbers). The flag property should still move in a
> monotonic direction (enabled -> disabled) or be immutable like the "internal"
> flag.
> 
> To simplify the addition of this new phase, we introduce many placeholder
> phases. They are not meant to be used for now. Keeping `allphases` as a list
> ensure existing algorithm works fine.
> 
> The full performance impact of adding that many hollow phases is unclear so
> far. The impact on phase computation is visible but not worrisome.
> 
> Runnin `hg perfphase` in my mercurial development repository.
> Before: ! wall 0.001807 comb 0.000000 user 0.000000 sys 0.000000 (median of 1597)
> after:  ! wall 0.001906 comb 0.000000 user 0.000000 sys 0.000000 (median of 1521)
> 
> diff --git a/mercurial/phases.py b/mercurial/phases.py
> --- a/mercurial/phases.py
> +++ b/mercurial/phases.py
> @@ -123,11 +123,22 @@ from . import (
>  
>  _fphasesentry = struct.Struct('>i20s')
>  
> -allphases = public, draft, secret = range(3)
> +INTERNAL_FLAG = 64 # Phases for mercurial internal usage only
> +HIDEABLE_FLAG = 32 # Phases that are hideable

Do we allocate large blocks for these phases so that we can add more similar
phases without introducing new repository-level requirement?

I didn't find any problem in this series, but I didn't follow the previous
discussion at all, so I leave it to someone who has expertise.