Boris Feld <boris.feld@octobus.net> [Wed, 12 Jul 2017 20:11:00 +0200] rev 33458
phases: track phase changes from 'retractboundary'
We adds new computation to find and record the revision affected by the
boundary retraction. This add more complication to the function but this seems
fine since it is only used in a couple of rare and explicit cases (`hg phase
--force` and `hg qimport`).
Having strong tracking of phase changes is worth the effort.
Boris Feld <boris.feld@octobus.net> [Wed, 12 Jul 2017 23:15:09 +0200] rev 33457
phases: detect when boundaries has been actually retracted
It is useful to detect noop and avoid expensive operations in this case.
We return the information to inform the caller of a possible update. Top level
function might need to react to the phase update (eg: invalidating some
caches, tracking phase change).
Boris Feld <boris.feld@octobus.net> [Tue, 11 Jul 2017 01:17:36 +0200] rev 33456
phases: rework phase movement code in 'cg.apply' to use 'registernew'
We rework the code to call 'registernew' before any other phase advancement.
This make 'changegroup.apply' register correct phase movement for the added
and bundled nodes.
Boris Feld <boris.feld@octobus.net> [Tue, 11 Jul 2017 00:59:23 +0200] rev 33455
convert: use the new 'phase.registernew' function
Boris Feld <boris.feld@octobus.net> [Tue, 11 Jul 2017 01:05:27 +0200] rev 33454
localrepo: use the 'registernew' function to set the phase of new commit
Boris Feld <boris.feld@octobus.net> [Tue, 11 Jul 2017 03:47:25 +0200] rev 33453
phases: add a 'registernew' method to set new phases
This new function will be used by code that adds new changesets. It ajusts the
phase boundary to make sure added changesets are at least in their target
phase (they end up in an higher phase if their parents are in a higher phase).
Having a dedicated function also simplify the phases tracking. All the new
nodes are passed as argument, so we know that all of them needs to have their
new phase registered. We also know that no other nodes will be affected, so no
extra computation are needed.
This function differ from 'retractboundary' where some nodes might change
phase while some other might not. It can also affect nodes not passed as
parameters.
These simplification also apply to the computation itself. For now we use
'_retractboundary' there by convenience, but we may introduces simpler code
later.
While registering new revisions, we still need to check the actual phases of
the added node because it might be higher than the target phase (eg: target is
draft but parent is secret).
We will migrate users over the next changesets.