bookmark: use 'applychanges' for bookmark deletion

bookmark: introduce a 'applychanges' function to gather bookmark movement We want to track bookmark movement within a transaction. For this we need a more centralized way to update bookmarks. For this purpose we introduce a new 'applychanges' method that apply a list of changes encoded as '(name, node)'. We'll cover all bookmark updating code to this new method in later changesets and add bookmark move in the transaction when all will be migrated.

obsstore: keep self._data updated with _addmarkers This makes sure obsstore._data is still correct with added markers. The '_data' propertycache was added in 17ce57b7873f.

match: make base matcher return True for visitdir If a matcher doesn't implement visitdir, we should be returning True so that tree traversals are not prematurely pruned. The old value of False would prevent tree traversals when using any matcher that didn't implement visitdir. Differential Revision: https://phab.mercurial-scm.org/D83

tests: fix an incorrect description in test-ignore.t Differential Revision: https://phab.mercurial-scm.org/D82

templatekw: hide {peerpaths} keyword for 4.3 Thinking a bit further about list/dict subscript operation (proposed by issue 5534), I noticed the current data structure, a dict of dicts, might not be ideal. For example, if there were "'[' index ']'" and "'.' key" operators, "{parents[0]}" would return "{p1rev}:{p1node}", and we would probably want to write "{parents[0].desc}" to get the first element of "{parents % "{desc}"}". This will basically execute parents[0].makemap()['desc'] in Python. Given the rule above, "{peerpaths.default.pushurl}" will be translated to peerpaths['default'].makemap()['pushurl'], which means {peerpaths} should be a single-level dict and sub-options should be makemap()-ed. "{peerpaths % "{name} = {url}, {pushurl}, ..."}" (Well, it could be peerpaths['default']['pushurl'], but in which case, peerpaths['default'] should be a plain dict, not a hybrid object.) So, let's mark the current implementation experimental and revisit it later.

parsers: fix invariant bug in find_deepest (issue5623) find_deepest is used to find the "best" ancestors given a list. In the main loop it keeps an invariant called 'ninteresting' which is supposed to contain the number of non-zero entries in the 'interesting' array. This invariant is incorrectly maintained, however, which leads the the algorithm returning an empty result for certain graphs. This has been fixed. Also, the 'interesting' array is supposed to fit 2^ancestors values, but is incorrectly allocated to twice that size. This has been fixed as well. The tests in test-ancestor.py compare the Python and C versions of the code, and report the error correctly, since the Python version works correct. Even so, I have added an additional test against the expected result, in the event that both algorithms have an identical error in the future. This fixes issue5623.

configitems: register the 'worker.backgroundclose' config

configitems: register the 'progress.width' config

configitems: register the 'color.pagermode' config

configitems: handle case were the default value is not static In some case, the default of one value is derived from other value. We add a way to register them anyway and an associated devel-warning. The registration is very naive for the moment. We might be able to have a better way for registering each of these cases but it could be done later.

bugzilla: move the default regexp for fix in the config declaration This mimic the change requested by Yuya for '_default_bug_re'.

configitems: register the 'bugzilla.version' config

configitems: register the 'bugzilla.usermap' config

configitems: register the 'bugzilla.user' config

configitems: register the 'bugzilla.timeout' config

configitems: register the 'bugzilla.template' config

configitems: register the 'bugzilla.style' config

configitems: register the 'bugzilla.strip' config

configitems: register the 'bugzilla.regexp' config The default value is moved from the class to the config registration.

changegroup: stop returning and recording added nodes in 'cg.apply' cg.apply used to returns the added nodes. Callers doesn't have a use for it anymore, remove the added node and stops recording it in the current operation. This information was added in the current release cycle so no extensions breakage should happens.

phases: remove trace of addednodes in the 'phase-heads' handling updatephases have no use of the 'addednodes' parameter since 50243c975fc2. However caller are still passing it for nothing, remove the parameter and remove computing of the added nodes in caller.

phases: test phases tracking at the transaction level Now that we have all tracking in place, the data in `tr.changes['phases']` dictionary should be correct and we should test it. It is a bit late in the cycle to discuss to add any public API (eg: hooks) that expose the data to the user, so we just add a small test extension displaying the data. It is enabled for the phases tests. New output have been manually checked for consistency.

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.

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).

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.

convert: use the new 'phase.registernew' function

localrepo: use the 'registernew' function to set the phase of new commit

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.

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.