devel-warn: issue a warning for old style revsets We have move to smartset class more than a year ago, we now have the tool to aggressively nudge developer into upgrading their extensions.

devel-warn: move the develwarn function as a method of the ui object We are going to use this feature in more and more place. Having to import scmutil makes it an import cycle hell.

templates: fix missing closing brace in map-cmdline.status Currently the parser does not validate the last closing brace, but future patches will make it less permissive for this kind of syntax errors.

verify: clarify misleading fncache message This is a message about cache corruption, not repository corruption or actually missing files. Fix message and reduce to a warning.

phase: add a pointer to 'hg help phases' in the 'phase' help The command and the general topic have very similar name. The topic is pointing to the command, but the command was not pointing to the topic.

publishing: unconditionally trust publishing flag Unfortunately, there are currently no tests for this behavior because we lack a good way of testing trust.

publishing: use new helper method

publishing: add helper method to localrepo

revset: make use of natively-computed set for 'draft()' and 'secret()' If the computation of a set for each phase (done in C) is available, we use it directly instead of applying a simple filter. This give a massive speed-up in the vast majority of cases. On my mercurial repo with about 15000 out of 40000 draft changesets: revset: draft() plain min first last 0) 0.011201 0.019950 0.009844 0.000074 1) 0.000284 2% 0.000312 1% 0.000314 3% 0.000315 x4.3 Bad performance for "last" come from the handling of the 15000 elements set (memory allocation, filtering hidden changesets (99% of it) etc. compared to applying the filter only on a handfuld of revisions (the first draft changesets being close of tip). This is not seen as an issue since: * Timing is still pretty good and in line with all the other one, * Current user of Vanilla Mercurial will not have 1/3 of their repo draft, This bad effect disappears when phase's set is smaller. (about 200 secrets): revset: secret() plain min first last 0) 0.011181 0.022228 0.010851 0.000452 1) 0.000058 0% 0.000084 0% 0.000087 0% 0.000087 19%

revset: refactor the non-public phase code Code for draft and secret are the same. We'll make it more complex to take advantages of the set recomputed in C, so we first refactor the code to only have one place to update (and make sure all behave properly). We do not refactor the 'public()' code because it does not have a natively computed set.

revset: translate node directly with changelog in 'head' Using 'repo[X]' is much slower because it creates a 'changectx' object and goes though multiple layers of code to do so. It is also error prone if there is tags, bookmarks, branch or other names that could map to a node hash and take precedence (user are wicked). This provides a significant performance boost on repository with a lot of heads. Benchmark result for a repo with 1181 heads. revset: head() plain min last reverse 0) 0.014853 0.014371 0.014350 0.015161 1) 0.001402 9% 0.000975 6% 0.000874 6% 0.001415 9% revset: head() - public() plain min last reverse 0) 0.015121 0.014420 0.014560 0.015028 1) 0.001674 11% 0.001109 7% 0.000980 6% 0.001693 11% revset: draft() and head() plain min last reverse 0) 0.015976 0.014490 0.014214 0.015892 1) 0.002335 14% 0.001018 7% 0.000887 6% 0.002340 14% The speed up is visible even when other more costly revset are in use revset: head() and author("mpm") plain min last reverse 0) 0.105419 0.090046 0.017169 0.108180 1) 0.090721 86% 0.077602 86% 0.003556 20% 0.093324 86%

revset: use a baseset in _notpublic() The '_notpublic()' internal revset was "returning" a set. That was wrong. We now return a 'baseset' as appropriate. This has no effect on performance in most case, because we do the exact same operation than what the combination with a 'fullreposet' was doing. This as a small effect on some operation when combined with other set, because we now apply the filtering in all cases. I think the correctness is worth the impact on some corner cases. The optimizer should take care of these corner cases anyway. revset #0: not public() plain min max first last reverse 0) 0.000465 0.000491 0.000495 0.000500 0.000494 0.000479 1) 0.000484 0.000503 0.000498 0.000505 0.000504 0.000491 revset #1: (tip~1000::) - public() plain min max first last reverse 0) 0.002765 0.001742 0.002767 0.001730 0.002761 0.002782 1) 0.002847 0.001777 0.002776 0.001741 0.002764 0.002858 revset #2: not public() and branch("default") plain min max first last reverse 0) 0.012104 0.011138 0.011189 0.011138 0.011166 0.011578 1) 0.011387 94% 0.011738 105% 0.014220 127% 0.011223 0.011184 0.012077 revset #3: (not public() - obsolete()) plain min max first last reverse 0) 0.000583 0.000556 0.000552 0.000555 0.000552 0.000610 1) 0.000613 105% 0.000559 0.000557 0.000573 0.000558 0.000613 revset #4: head() - public() plain min max first last reverse 0) 0.010869 0.010800 0.011547 0.010843 0.010891 0.010891 1) 0.011031 0.011497 106% 0.011087 0.011100 0.011100 0.011085

contrib: clean up all-revsets.txt file I forgot to cleanup a handful of them when I originally created the file.

hgweb: link to revision by node hash in paper & coal Unlike other styles, paper and coal had only one link to current revision: in the sidebar. Since those links now use symbolic revisions after 3bb6f5f478a7, it's nice to have a link that allows going from /rev/tip to /rev/<tip hash>, for instance. Let's make the node hash in the page header that new link.

hgweb: link to revision by node hash in gitweb & monoblue This allows going from /rev/tip to /rev/<tip hash> with ease.