Tue, 11 Jul 2017 00:59:23 +0200 convert: use the new 'phase.registernew' function
Boris Feld <boris.feld@octobus.net> [Tue, 11 Jul 2017 00:59:23 +0200] rev 33455
convert: use the new 'phase.registernew' function
Tue, 11 Jul 2017 01:05:27 +0200 localrepo: use the 'registernew' function to set the phase of new commit
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
Tue, 11 Jul 2017 03:47:25 +0200 phases: add a 'registernew' method to set new phases
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.
Mon, 10 Jul 2017 23:50:16 +0200 phases: extract the core of boundary retraction in '_retractboundary'
Boris Feld <boris.feld@octobus.net> [Mon, 10 Jul 2017 23:50:16 +0200] rev 33452
phases: extract the core of boundary retraction in '_retractboundary' At the moment the 'retractboundary' function is called for multiple reasons: First, actually retracting boundaries. There are only two cases for theses: 'hg phase --force' and 'hg qimport'. This will need extra graph computation to retrieve the phase changes. Second, setting the phases of newly added changesets. In this case we already know all the affected nodes and we just needs to register different information (old phase is None). Third, when reducing the set of roots when advancing phase. The phase are already properly tracked so we do not needs anything else in this case. To deal with this difference in phase tracking, we extract the core logic into a private method that all three cases can use.
Tue, 11 Jul 2017 02:39:52 +0200 phases: track phase movements in 'advanceboundary'
Boris Feld <boris.feld@octobus.net> [Tue, 11 Jul 2017 02:39:52 +0200] rev 33451
phases: track phase movements in 'advanceboundary' Makes advanceboundary record the phase movement of affected revisions in tr.changes['phases']. The tracking is not usable yet because the 'retractboundary' function can also affect phases. We'll improve that in the coming changesets.
Mon, 10 Jul 2017 22:18:41 +0200 phases: extract the intermediate set of affected revs
Boris Feld <boris.feld@octobus.net> [Mon, 10 Jul 2017 22:18:41 +0200] rev 33450
phases: extract the intermediate set of affected revs When advancing phases, we compute the new roots for the phases above. During this process, we need to compute all the revisions that change phases (to the new target phases). Extract these revisions into a separate variable. This will be useful to record the phase changes in the transaction.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip