Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 10 Jun 2015 19:26:16 -0700] rev 25527
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
Anton Shestakov <av6@dwimlabs.net> [Fri, 12 Jun 2015 18:34:10 +0800] rev 25526
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'.
Anton Shestakov <av6@dwimlabs.net> [Fri, 12 Jun 2015 16:09:59 +0800] rev 25525
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'.
Anton Shestakov <av6@dwimlabs.net> [Fri, 12 Jun 2015 15:29:12 +0800] rev 25524
hgweb: put help link in paper/search.tmpl separately for consistency
Just a cosmetic markup change, no .css changes required.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 11 Jun 2015 00:26:06 -0700] rev 25523
help: use 'color' as an example (instead of 'progress')
Progress is now deprecated, using it as an example is suboptimal.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 08 Jun 2015 01:01:21 -0700] rev 25522
progress: deprecate the progress extension
Activating it is a absolute no-op now.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 08 Jun 2015 01:00:47 -0700] rev 25521
progress: empty the extension of any logic
The default value match the one enforce by the extension, we can remove that
logic.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 10 Jun 2015 11:56:55 -0700] rev 25520
progress: move config help into core config help
This is core feature now.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 07 Jun 2015 17:51:27 -0700] rev 25519
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.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 07 Jun 2015 15:57:54 -0700] rev 25518
bundle2: provide number of changesets information to 'addchangegroup'
We can now link the two efforts and provided more useful information when
pulling changesets.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 07 Jun 2015 15:57:40 -0700] rev 25517
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.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 07 Jun 2015 15:52:57 -0700] rev 25516
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.
Matt Mackall <mpm@selenic.com> [Wed, 10 Jun 2015 14:38:09 -0500] rev 25515
tests: test basic template support for status
Matt Mackall <mpm@selenic.com> [Wed, 10 Jun 2015 14:35:05 -0500] rev 25514
templates: add a default template style for status
Color doesn't work yet, so no labels here.
Matt Mackall <mpm@selenic.com> [Wed, 10 Jun 2015 14:33:38 -0500] rev 25513
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)
Matt Mackall <mpm@selenic.com> [Wed, 10 Jun 2015 14:30:18 -0500] rev 25512
formatter: add a method to build a full templater from a -T option
Matt Mackall <mpm@selenic.com> [Wed, 10 Jun 2015 14:29:13 -0500] rev 25511
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.
Yuya Nishihara <yuya@tcha.org> [Wed, 10 Jun 2015 22:08:15 +0900] rev 25510
color: copy docstring of label() template function to wrapper
Otherwise label() wouldn't be listed in "hg help template" if color extension
is enabled.
Yuya Nishihara <yuya@tcha.org> [Mon, 08 Jun 2015 18:48:45 +0900] rev 25509
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.
Matt Harbison <matt_harbison@yahoo.com> [Sat, 06 Jun 2015 22:10:18 -0400] rev 25508
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.
Martin von Zweigbergk <martinvonz@google.com> [Wed, 10 Jun 2015 14:49:27 -0700] rev 25507
bundle2: clarify in docstring that header size is for a single header
The docstring for the header size field currently says "The total
number of Bytes used by the part headers", but the size is about a
single header, so let's change it to "header".
Martin von Zweigbergk <martinvonz@google.com> [Wed, 10 Jun 2015 14:47:24 -0700] rev 25506
bundle2: rename duplicate handlepushkeyreply to handleobsmarkerreply
The function was only called through the parthandlermapping dict, so
it was confusing but safe in practice.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 07 Jun 2015 15:49:57 -0700] rev 25505
changegroup: remove 'getchangegroupraw' function
There is no remaining caller for this function.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 07 Jun 2015 15:49:17 -0700] rev 25504
exchange: expand usage of getchangegroupraw
The 'getchangegroupraw' is very simple (two lines) so we inline it in its only
caller. This exposes the 'outgoing' object of the part generator function, allowing
us to add information on the number of changesets contained in the part in a
later changeset. Such information is useful for progress bar.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 07 Jun 2015 15:47:07 -0700] rev 25503
getbundle: have a single getchangegroupraw call site
Having a single call site will simplify the code and help with coming refactoring.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 27 May 2015 22:25:51 -0700] rev 25502
phases: abort the whole push if phases fail to update (BC)
When using bundle2, the phase pushkey parts are now made mandatory. As a
result, failure to update the bookmark server side will result in the transaction
being aborted.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 27 May 2015 22:25:33 -0700] rev 25501
bookmarks: abort the whole push if bookmarks fails to update (BC)
When using bundle2, the bookmark's pushkey parts are now made mandatory. As a
result failure to update the bookmark server side will result in the transaction
being aborted.
Kyle Lippincott <spectral@google.com> [Mon, 08 Jun 2015 16:55:21 -0700] rev 25500
httppeer: allow extensions to replace urllib2.Request
The authentication library my extension wants to use requires using a different
opener and a different request builder. This change pulls the call to
urllib2.Request out so that my extension can replace it just like it can
replace urlopener.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 07 Jun 2015 17:50:56 -0700] rev 25499
progress: move all logic altering the ui object logic in mercurial.ui
The ui object can take care of its progress object logic by itself.
test-subrepo-recursion is modified because it is a bit sensitive to the "no
progress bar" default. It will become unnecessary in the next step when
progress will be on by default in core.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 07 Jun 2015 17:26:34 -0700] rev 25498
progress: move the singleton logic to the ui module
The use of a singleton for all of progress handling is debatable (because
config may vary). However this is how the extension has been doing it so far.
We move that code into the ui module because this is where is should belong when
progress is moved into core.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 07 Jun 2015 17:19:20 -0700] rev 25497
progress: move most extension code into a 'mercurial.progress' module
This initiate the relocation of progress into core.
Matt Harbison <matt_harbison@yahoo.com> [Tue, 09 Jun 2015 23:40:13 -0400] rev 25496
test-subrepo-recursion: restore globs for Windows