revsetbenchmarks: display relative change when meaningful If the time difference is more than 5% from the previous run, we'll display relative information. This makes it much simpler to spot performance changes in a sea of benchmarks.

revsetbenchmarks: improve revision printing We now print the revision number and short hash inline. As a result we drop the crappy list printing.

revsetbenchmarks: hide most timing under a --verbose flag We mostly only care about total time. Dropping this output give us some room to display more useful information (like percentage different) in future changesets.

revsetbenchmarks: drop outdated comment We are no longer testing against system mercurial for quite some time.

revsetbenchmarks: fix argument parsing The file doc was saying something, the code was doing something else, the argument validation was doing a third thing. Doc and behavior now comply with the argument defined in the code.

revsetbenchmarks: use a more compact output format with a header We change the output from: revset #0: draft() 0) wall 0.011989 comb 0.010000 user 0.000000 sys 0.010000 (best of 177) 1) wall 0.012226 comb 0.010000 user 0.000000 sys 0.010000 (best of 193) 2) wall 0.011838 comb 0.020000 user 0.000000 sys 0.020000 (best of 208) to: revset #0: draft() wall comb user sys count 0) 0.012028 0.010000 0.000000 0.010000 170 1) 0.012218 0.010000 0.000000 0.010000 157 2) 0.012622 0.010000 0.000000 0.010000 189 This opens the road to more useful output.

revsetbenchmarks: clarify comment based on irc discussion

revsetbenchmarks: ensure all indexes have the same width This avoids an alignment glitch.

revsetbenchmarks: factor out result output into a function This will make update of the output easier.

revsetbenchmarks: parse perfrevset output into actual number We cannot just ask perfrevset to provide debug output because we usually want to compare output from old version of Mercurial that do not support it. So, we are using a regular expression. (/we now have \d problems/).

revsetbenchmarks: improve error output in case of failure This helps with diagnostics.

revsetbenchmarks: extract call to mercurial into a function This is a gratuitous change to make the code easier to look at.

phases: really fix native phase computation For some reason (probably rebase issue, leprechaun or badly resolved .rej) 1635579f9baf contains only half of the emailed patches and do not fix the bug. This patch adds the other half and enable the sweet native computation for real. As expected this provide massive speedup along the board. revset #0: not public() plain first 0) 0.011960 0.010523 1) 0.000465 3% 0.000492 4% revset #1: (tip~1000::) - public() plain first 0) 0.025700 0.025169 1) 0.002864 11% 0.001899 7% revset #2: not public() and branch("default") plain first 0) 0.022842 0.020863 1) 0.011418 49% 0.010948 52% However, it has a less impact (even bad) on first result time in simple situation. This comes from the overhead of building the set and filtering it. This is especially true on my Mercurial repository (used here) where about 1/3 of the changesets are non public and hidden. This could be mitigated by a caching of the set and a better usage of smartset in '_notpublic'. (But this won't happen in this patch because the win is massive everywhere else). revset #0: not public() last 0) 0.000081 1) 0.000493 x6.1 <-- bad impact revset #1: (tip~1000::) - public() last 0) 0.013966 1) 0.002737 19% revset #2: not public() and branch("default") last 0) 0.011021 1) 0.011038 The effect mostly disappear when the number of non-public changesets is small and/or the repo get bigger. Result for Mozilla central: Mozilla revset #0: not public() plain first last 0) 0.092787 0.084094 0.000080 1) 0.000054 0% 0.000083 0% 0.000083 revset #1: (tip~1000::) - public() plain first last 0) 0.215607 0.183996 0.124962 1) 0.031620 14% 0.006616 3% 0.031168 24% revset #2: not public() and branch("default") plain first last 0) 0.092626 0.082687 0.000162 1) 0.000139 0% 0.000165 0% 0.000167

hgweb: don't point file links at tip hash where it doesn't make sense Some pages, e.g. bookmarks, help and summary don't have a meaningful revision context: they always either show information about tip or about the whole repo (and not about any specific changeset). And error pages can just show hgweb error messages, not related to any repo or changeset. Having a hash in the links worked (even when '{node|short}' resolved to an empty string on error pages), but seeing pages without revision context provide links with hashes is a bit confusing (unless you keep current tip hash in your head at all times) and not consistent with other template styles and other links on the same page: they don't have a hash. Let's just link to '/file', which is equal to '/file/tip'.

hgweb: don't point graph links at tip hash where it doesn't make sense Some pages, e.g. bookmarks, help and summary don't have a meaningful revision context: they always either show information about tip or about the whole repo (and not about any specific changeset). And error pages can just show hgweb error messages, not related to any repo or changeset. When monoblue style was added in 91b0ada2d94b, however, all graph links had tried to point at some hash, and on such pages as described above it didn't make sense. On error pages '{node|short}' is empty string anyway. Of course, it worked, but seeing such pages without revision context provide links with hashes is a bit confusing (unless you keep current tip hash in your head at all times) and wasn't consistent with other template styles, other pages in monoblue and even other links on the same page. Let's just link to '/graph', which is equal to '/graph/tip'.

hgweb: put help link in paper/search.tmpl separately for consistency Just a cosmetic markup change, no .css changes required.

help: use 'color' as an example (instead of 'progress') Progress is now deprecated, using it as an example is suboptimal.

progress: deprecate the progress extension Activating it is a absolute no-op now.

progress: empty the extension of any logic The default value match the one enforce by the extension, we can remove that logic.

progress: move config help into core config help This is core feature now.

progress: display progress bars by default with core Mercurial As discussed multiple time during sprint, we should activate progress by default. Having progress bar significantly improve the user experience.

bundle2: provide number of changesets information to 'addchangegroup' We can now link the two efforts and provided more useful information when pulling changesets.

addchangegroup: accept an expected total number of changesets as argument Caller can optionally informs how much changesets are expected to be added. This will be used for a more useful progress bar output.

getbundle: add data about the number of changesets bundled We use an advisory parameters to carry the number of changesets bundled. This will be used for progress output.

tests: test basic template support for status

templates: add a default template style for status Color doesn't work yet, so no labels here.

formatter: add template support This lets all the non-log commands that use the formatter use templates. There are still some things that don't work, for instance: - color (needs "repo" in map) - shortest (needs "ctx" in map)

formatter: add a method to build a full templater from a -T option

formatter: move most of template option helper to formatter We want to share this function between formatter and cmdutils. It doesn't belong in templater because it imports knowledge of ui layers that shouldn't be there. We'd prefer cmdutil to layer on the formatter rather than vice-versa. Since the formatter is the handler for -T options for all non-log commands, let's move the helper there. We leave the bits specific to the old --style option behind.

color: copy docstring of label() template function to wrapper Otherwise label() wouldn't be listed in "hg help template" if color extension is enabled.

templater: make pad function evaluate both string and rawstring templates "pad" function and "rawstring" type were introduced in parallel, aa51392da507 in default and 5ab28a2e9962 in stable respectively. Therefore, "pad" function lacked handling of "rawstring" unintentionally.

largefiles: ignore hidden changesets with 'verify --large --lfa' Previously, if there were any hidden changesets, the --lfa argument would cause the command to abort with a hint about using --hidden when it tripped over a hidden changeset.