Sun, 04 Mar 2018 16:23:03 -0500 tests: stop over-specifying tempfile name
Augie Fackler <augie@google.com> [Sun, 04 Mar 2018 16:23:03 -0500] rev 36992
tests: stop over-specifying tempfile name Python 3 has more random characters in the default template, which is fine. Differential Revision: https://phab.mercurial-scm.org/D2676
Sat, 10 Mar 2018 23:58:01 -0500 wireproto: explicitly flush stdio to prevent stalls on Windows
Matt Harbison <matt_harbison@yahoo.com> [Sat, 10 Mar 2018 23:58:01 -0500] rev 36991
wireproto: explicitly flush stdio to prevent stalls on Windows This is the key to fixing the hangs on Windows in D2720[1]. I put flushes in a bunch of other places that didn't help, but I suspect that's more a lack of test coverage than anything else. Chasing down stuff like this is pretty painful. I'm wondering if we can put a proxy around sys.stderr (and sys.stdout?) on Windows (only when daemonized?) that will flush on every write (or at least every write with a '\n'). [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-March/113352.html
Sun, 18 Mar 2018 15:32:49 -0400 test-lfs: glob over some output changes
Matt Harbison <matt_harbison@yahoo.com> [Sun, 18 Mar 2018 15:32:49 -0400] rev 36990
test-lfs: glob over some output changes These changes started with 2090044a288d. They aren't important to LFS testing.
Fri, 16 Mar 2018 21:24:12 +0900 templater: factor out helper that renders named template as string
Yuya Nishihara <yuya@tcha.org> [Fri, 16 Mar 2018 21:24:12 +0900] rev 36989
templater: factor out helper that renders named template as string This is quite common in non-web templating, and **kwargs expansion is annoying because of the unicode-ness of Python3.
Sat, 17 Mar 2018 11:23:04 +0900 templater: rename .render(mapping) to .renderdefault(mapping) (API)
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Mar 2018 11:23:04 +0900] rev 36988
templater: rename .render(mapping) to .renderdefault(mapping) (API) I'm going to add templ.render(t, mapping) and templ.generate(t, mapping) in place of stringify(templ(t, **mapping)) and templ(t, **mapping) respectively. .. api:: The ``render(mapping)`` method of the templater has been renamed to ``renderdefault(mapping)``.
Sat, 17 Mar 2018 15:22:14 +0900 templater: fix invalid reference of runsymbol in doctest
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Mar 2018 15:22:14 +0900] rev 36987
templater: fix invalid reference of runsymbol in doctest Oversight at da710c3df4dc. I was just lucky that this lambda function is never evaluated.
Sun, 18 Mar 2018 12:54:03 +0900 cmdutil: drop redundant import of merge module
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 12:54:03 +0900] rev 36986
cmdutil: drop redundant import of merge module
Sun, 11 Mar 2018 21:36:28 +0900 annotate: add support for template keywords and functions depending on ctx
Yuya Nishihara <yuya@tcha.org> [Sun, 11 Mar 2018 21:36:28 +0900] rev 36985
annotate: add support for template keywords and functions depending on ctx
Sun, 11 Mar 2018 21:26:15 +0900 formatter: unblock storing fctx as a template resource
Yuya Nishihara <yuya@tcha.org> [Sun, 11 Mar 2018 21:26:15 +0900] rev 36984
formatter: unblock storing fctx as a template resource To keep templateformatter._renderitem() simple, a repo instance is looked through ctx if available. This is probably good for future subrepo support where ctx.repo() may be different from the global repo.
Sun, 11 Mar 2018 21:12:02 +0900 templater: process mapping dict by resource callables
Yuya Nishihara <yuya@tcha.org> [Sun, 11 Mar 2018 21:12:02 +0900] rev 36983
templater: process mapping dict by resource callables A resource item is a callable, so let's make it look up a resource object by itself.
Sun, 11 Mar 2018 21:05:29 +0900 templater: convert resources to a table of callables for future extension
Yuya Nishihara <yuya@tcha.org> [Sun, 11 Mar 2018 21:05:29 +0900] rev 36982
templater: convert resources to a table of callables for future extension I'm going to add a full templating support to the annotate command. As the annotate is a filectx-oriented command, we'll need a way to look up a ctx from a bounded fctx only when necessary. This is the minimal change to support that. I'm thinking of defining a proper interface to look up template resources to fix other issues, but that isn't ready yet. (Changes from V1: just updated tests and patch descriptions.)
Thu, 15 Mar 2018 22:35:07 -0700 rebase: on abort, don't strip commits that didn't need rebased (issue5822) stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Mar 2018 22:35:07 -0700] rev 36981
rebase: on abort, don't strip commits that didn't need rebased (issue5822) I clearly missed adding this condition in 78496ac30025 (rebase: allow rebase even if some revisions need no rebase (BC) (issue5422), 2017-05-11). Perhaps I should have opted for the "revdone" solution I mentioned there... Differential Revision: https://phab.mercurial-scm.org/D2879
Thu, 15 Mar 2018 21:40:51 -0700 rebase: avoid defining two lists with the same contents stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Mar 2018 21:40:51 -0700] rev 36980
rebase: avoid defining two lists with the same contents In abort(), there's "dstates" and "rebased" that are identical, which they seem to have been since 0806823370d8 (rebase: properly calculate descendant set when aborting (issue3332), 2012-03-22). Let's de-duplicate. I don't know what "dstates" means, but "rebased" makes sense (it's the list of rebased revisions), so let's pick that. Differential Revision: https://phab.mercurial-scm.org/D2878
Thu, 15 Mar 2018 21:51:33 -0700 tests: demonstrate aborted rebase strips commits that didn't need rebasing stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Mar 2018 21:51:33 -0700] rev 36979
tests: demonstrate aborted rebase strips commits that didn't need rebasing I haven't verified, but this has probably been broken ever since I added the feature in 78496ac30025 (rebase: allow rebase even if some revisions need no rebase (BC) (issue5422), 2017-05-11). Differential Revision: https://phab.mercurial-scm.org/D2877
Sat, 17 Mar 2018 21:46:17 -0400 merge with stable
Augie Fackler <augie@google.com> [Sat, 17 Mar 2018 21:46:17 -0400] rev 36978
merge with stable
Fri, 16 Mar 2018 12:10:15 -0700 hgweb: convert an assert to a ProgrammingError
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 16 Mar 2018 12:10:15 -0700] rev 36977
hgweb: convert an assert to a ProgrammingError Because assert may get optimized away. Differential Revision: https://phab.mercurial-scm.org/D2882
Fri, 19 Jan 2018 18:52:50 -0800 filemerge: give some variables in _xmerge more descriptive names
Kyle Lippincott <spectral@google.com> [Fri, 19 Jan 2018 18:52:50 -0800] rev 36976
filemerge: give some variables in _xmerge more descriptive names Differential Revision: https://phab.mercurial-scm.org/D2886
Thu, 15 Mar 2018 13:19:55 -0700 rebase: allow in-memory merge of the working copy parent
Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Mar 2018 13:19:55 -0700] rev 36975
rebase: allow in-memory merge of the working copy parent Before this patch and when the rebase involved the working copy parent (and thus the working copy too), we would not do in-memory rebase even if requested to. The in-code comment explains that the reason had something to do with avoiding an extra update, but I don't know which update that refers to. Perhaps an earlier version of the code used to update to the destination before rebasing even if in-memory rebase was requested? That seems to not be done at least since aa660c1203a9 (rebase: do not bail on uncomitted changes if rebasing in-memory, 2017-12-07). To see if this still made it slower, I create a single tiny commit on top of one branch of the mozilla-unified repo (commit a1098c82 to be exact) and rebased it to another branch (commit d4e9a7be). Before this patch that took 11.8s and after this patch it took 8.6s (I only did two runs each, but the timings were very consistent). Differential Revision: https://phab.mercurial-scm.org/D2876
Sat, 17 Mar 2018 09:33:17 -0700 uncommit: simplify condition for keeping commit
Martin von Zweigbergk <martinvonz@google.com> [Sat, 17 Mar 2018 09:33:17 -0700] rev 36974
uncommit: simplify condition for keeping commit We used to keep the commit if it would have become empty and --keep was not passed. Since we just changed it so we also keep it if any patterns were passed on the command line, the only remaining case where we prune the commit is when no arguments were passed and --keep was not passed either, we can simplify the "not files and not allowempty" to just "not allowempty". Let's also rename "allowempty" to "keepcommit" since it's no longer about allowing an empty commit. Differential Revision: https://phab.mercurial-scm.org/D2891
Sat, 17 Mar 2018 09:49:21 -0700 uncommit: document when the commit will be pruned
Martin von Zweigbergk <martinvonz@google.com> [Sat, 17 Mar 2018 09:49:21 -0700] rev 36973
uncommit: document when the commit will be pruned Differential Revision: https://phab.mercurial-scm.org/D2890
Wed, 14 Mar 2018 11:16:49 -0700 uncommit: leave empty commit if all files are uncommitted
Martin von Zweigbergk <martinvonz@google.com> [Wed, 14 Mar 2018 11:16:49 -0700] rev 36972
uncommit: leave empty commit if all files are uncommitted We had instructions for our internal users to add copy information after commit like this: hg uncommit <srcfile> <dstfile> hg cp --after <srcfile> <dstfile> hg amend That usually works, but if the rename was the only change in that commit, then the commit would get pruned. It's easy to fix the recipe: just pass the --keep option. However, it seems too subtle, so I think this is an indication that the commit should not be pruned if any patterns were given. Differential Revision: https://phab.mercurial-scm.org/D2862
Sat, 17 Mar 2018 00:06:14 +0900 test-template-engine: do not evaluate unused keywords by custom engine
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Mar 2018 00:06:14 +0900] rev 36971
test-template-engine: do not evaluate unused keywords by custom engine If the custom engine, "mytemplater", were installed as the default, it would enter to an infinite recursion at stringify(v) because template keywords may generate a nested mapping containing the same keywords. Spotted by a future patch which will replace context.resource('templ')(...) with context.process(...).
Fri, 16 Mar 2018 23:59:13 +0900 py3: make test-template-engine.t bytes-safe
Yuya Nishihara <yuya@tcha.org> [Fri, 16 Mar 2018 23:59:13 +0900] rev 36970
py3: make test-template-engine.t bytes-safe
Thu, 15 Mar 2018 20:10:54 +0900 test-template-engine: deduplicate methods of custom template engine
Yuya Nishihara <yuya@tcha.org> [Thu, 15 Mar 2018 20:10:54 +0900] rev 36969
test-template-engine: deduplicate methods of custom template engine
Thu, 18 Jan 2018 15:10:22 +0100 revbranchcache: advertise and use 'rbc' exchange capability
Boris Feld <boris.feld@octobus.net> [Thu, 18 Jan 2018 15:10:22 +0100] rev 36968
revbranchcache: advertise and use 'rbc' exchange capability The feature is now advertised and use. Updating the branchmap cache can be very expensive (up to minutes on large repository) and fetching revision branch data is about 80% of that. Exchanging the rev branch cache over the wire really help to recover from branch map invalidation. (There is a good chance other in flight chance would conflict on test-http-bad-server.t and other. So here is a small note to help update that test again: capabilities=19bytes, part-107bytes)
Wed, 21 Feb 2018 19:26:41 +0100 revbranchcache: disable the new part for narrow hg bundle
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 19:26:41 +0100] rev 36967
revbranchcache: disable the new part for narrow hg bundle The lack of some revisions confuses the new cache part. To simplify things, we disable it for now.
Thu, 18 Jan 2018 14:58:02 +0100 revbranchcache: add the necessary bit to send 'rbc' data over bundle2
Boris Feld <boris.feld@octobus.net> [Thu, 18 Jan 2018 14:58:02 +0100] rev 36966
revbranchcache: add the necessary bit to send 'rbc' data over bundle2 Getbundle is now capable of sending rev-branch-cache information for the changesets it bundle. The data sent are mostly nodes so it is quite compact. The goal of the rev-branch-cache is to speed up branch map computation, especially when the branchmap gets invalidated so we send data for all exchanged changesets. In addition, computing the relevant heads to send in case of partial pulling would be challenging. The feature is still inactive since the capability is not advertised yet.
Wed, 21 Feb 2018 17:33:00 +0100 bundle: include advisory rev branch cache part in bundle2 bundle
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 17:33:00 +0100] rev 36965
bundle: include advisory rev branch cache part in bundle2 bundle `hg bundle` command producing bundle2 will now include an optional part containing the revision-branch cache data. The data sent are mostly nodes so it is quite compact. The goal of the rev-branch-cache is to speed up branch map computation, especially when the branchmap gets invalidated so we send data for all exchanged changesets. In addition, computing the relevant heads to send in case of partial pulling would be challenging. As a reminder, the rev branch cache data significantly speed up branch computation. Having it around provides a small speedup to pull/clone and much higher tolerance to branch map cache invalidation that might happens from later commands. On the Mercurial repository, computing the visible branchmap from scratch move from 2.00 seconds to 0.34s (a -83% speedup). Using this new part, Unbundling the full Mercurial repository moves from 25.736 seconds to 24.030 seconds (around -7% speedup). The bundle size increase is around 3% (from 22.43 MB to 23.13MB) On an half a million revision repository with twenty thousand branches, computing the branchmap moves from 75 seconds to 45 second (-40%) if the caches is used. A bundle containing 50 000 changesets in such repository get a 0.5% size increase from such part for a -3% unbundling time speedup.
Wed, 21 Feb 2018 17:26:22 +0100 rev-branch-cache: add a function to generate a part
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 17:26:22 +0100] rev 36964
rev-branch-cache: add a function to generate a part The function is able to produce a rbc part consumed by the function introduced into previous changesets. More details on usage and impact in the next changesets.
Wed, 21 Feb 2018 17:35:04 +0100 revbranchcache: add a bundle2 handler for a rbc part
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 17:35:04 +0100] rev 36963
revbranchcache: add a bundle2 handler for a rbc part We add the necessary bit to process a part containing rev-branch-cache information. The local rev branch cache is then updated with the received information. Computing branch cache can become a significant part of the time spent pulling.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip