bookmark: use 'applychanges' when stripping

bookmark: use 'applychanges' in the convert extension

bookmark: use 'applychanges' when updating bookmark in histedit

bookmark: use 'applychanges' when updating a bookmark through pushkey

bookmark: use 'applychanges' when updating from a remote

bookmark: use 'applychanges' for adding new bookmark

bookmark: use 'applychanges' for bookmark renaming

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.

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.

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.

phase: put retractboundary out of the loop in advanceboundary It seems that we were calling retractboundary for each phases to process. Putting the retractboundary out of the loop reduce the number of calls, helping tracking the phases changes.

match: make unionmatcher a proper matcher unionmatcher is currently used where only a limited subset of its functions will be called. Specifically, visitdir() is never called. The next patch will pass it to dirstate.walk() where it will matter that visitdir() is correctly implemented, so let's fix that. Also add the explicitdir etc that will also be assumed by dirstate.walk() to exist on a matcher. Differential Revision: https://phab.mercurial-scm.org/D58

match: write forceincludematcher using unionmatcher The forceincludematcher is simply a unionmatcher of a includematcher (matching paths recursively) with the given matcher. Since the forceincludematcher is only used by sparse, move it there. I don't have a good sparse repo setup to test performance impact on. Differential Revision: https://phab.mercurial-scm.org/D57

histedit: extract InterventionRequired transaction handling to utils rebase will have similar logic, so let's extract it. Besides, it makes the histedit code more readable. We may want to parametrize acceptintervention() by the exception(s) that should result in transaction close. Differential Revision: https://phab.mercurial-scm.org/D66

histedit: create transaction outside of try Just a little refactoring to simplify the next patch. Differential Revision: https://phab.mercurial-scm.org/D65

histedit: remove transaction from state object The transaction is only used within a single function, so no need to store it on the state object. Differential Revision: https://phab.mercurial-scm.org/D64

phabricator: verify local tags before trusting them Previously we trust local tags blindly and that could cause wrong Differential Revision to be updated, when people switch between Phabricator instances. This patch adds verification logic to detect such issue and remove problematic tags. For example, a tag "D19" was on node "X", the code will fetch all diffs attached to D19, and check if nodes server-side overlaps with nodes in precursors. If they do not overlap, create a new Differential Revision. Test Plan: Use a test Phabricator instance, send patches using `hg phabsend`, then change the local tag manually to a wrong Differential Revision number. Amend the patch and send again. Make sure the tag gets ignored and deleted. Differential Revision: https://phab.mercurial-scm.org/D36

phabricator: finding old nodes in batch This allows us to do extra sanity checks using batch APIs to prevent updating a wrong revision, which could happen when people switch Phabricator instances and having stale tags living in the repo. Differential Revision: https://phab.mercurial-scm.org/D34

phabricator: respect metadata sent by arc Previously we only respect hg:meta sent by phabsend. This patch makes it respect local:commits sent by arc as well. This avoids issues where phabread could lose the author information. Test Plan: Commit using a customized user, send the patch using arc to a test Phabricator instance, and then read the patch using phabread. Make sure it preserves the user information. Differential Revision: https://phab.mercurial-scm.org/D33