Thu, 25 Apr 2019 15:30:40 -0700 histedit: Speed up scrolling in patch view mode
feyu@google.com [Thu, 25 Apr 2019 15:30:40 -0700] rev 42234
histedit: Speed up scrolling in patch view mode Store patchcontents into the mode state, avoiding the expensive call to ui for computing the patchcontents. Before this change in large repos histedit patch view mode can be very irresponsive.
Thu, 02 May 2019 16:43:34 -0700 histedit: Show file names in multiple line format
Yu Feng <rainwoodman@gmail.com> [Thu, 02 May 2019 16:43:34 -0700] rev 42233
histedit: Show file names in multiple line format
Fri, 03 May 2019 20:06:03 +0900 parser: fix crash by parsing "()" in keyword argument position stable
Yuya Nishihara <yuya@tcha.org> [Fri, 03 May 2019 20:06:03 +0900] rev 42232
parser: fix crash by parsing "()" in keyword argument position A tree node can be either None or a tuple because x=("group", None) is reduced to x[1].
Sat, 06 Apr 2019 17:46:19 +0200 repoview: introduce a `experimental.extra-filter-revs` config
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 06 Apr 2019 17:46:19 +0200] rev 42231
repoview: introduce a `experimental.extra-filter-revs` config The option define revisions to additionally filter out of all repository "view". The end goal is to provide and easy to way to serve multiple subset of the same repository using multiple "shares". The simplest use case of this feature is to have one view serving the public changesets and one view also serving the draft. This is currently achievable using the new `server.view` option introduced recently by Joerg Sonnenberger. However, more advanced use cases need more advanced definitions. For example some needs a view dedicated to some release branches, or view that hides security fixes to be released. Joerg Sonnenberger and I discussed this topic at the recent mini-sprint and the both of us have seen real life use cases for this. (This series got written during the same mini-sprint). The feature is fully functional, and use similar cache-fallback mechanism to ensure decent performance. However,there remaining room to ensure each share caches and hooks collaborate with each others. This will come at a later time once users start to actually test this feature on real usecase.
Wed, 17 Apr 2019 23:10:29 -0700 copies: filter out copies from non-existent source later in _chain()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 17 Apr 2019 23:10:29 -0700] rev 42230
copies: filter out copies from non-existent source later in _chain() _changesetforwardcopies() repeatedly calls _chain(). That is very expensive because _chain() does lookups in the manifest. I hope to split up the function in two parts: 1) simple chaining, not considering end points, and 2) filter out files that don't exist in the end points (and ping-pong copies/renames). This patches gets us closer to that by moving the check for non-existent source later in the function. Now there are no more checks for "src" and "dst" in the first loop; all the filtering of invalid copies is done in the second loop. The code also looks much more consistent now. No measureable impact on `hg debugpathcopies 4.0 4.8`. That shouldn't be surprising since the only case we're doing more checks now is in case of chained copies/renames, which are quire rare in practice. Differential Revision: https://phab.mercurial-scm.org/D6277
Thu, 18 Apr 2019 00:12:56 -0700 copies: clarify mutually exclusive cases in _chain() with a s/if/elif/
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 00:12:56 -0700] rev 42229
copies: clarify mutually exclusive cases in _chain() with a s/if/elif/ If the 'b' dict has a rename from 'x' to 'y', it shouldn't be possible for 'x' to be both (a key) in 'a' and in 'src'. That would mean that 'x' is a file in the source commit and also a rename destination in the intermediate commit. But we currently don't allow renaming files onto existing files, so that shouldn't happen. So let's clarify that by using an "elif" instead of an "if". And if we did allow renaming files onto existing files, we should prefer to use the rename destination in the intermediate commit as source anyway. Differential Revision: https://phab.mercurial-scm.org/D6276
Thu, 18 Apr 2019 00:05:05 -0700 copies: delete a redundant cleanup step in _chain()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 00:05:05 -0700] rev 42228
copies: delete a redundant cleanup step in _chain() The check is redundant since d5edb5d3a337 (copies: filter out copies when target is not in destination manifest, 2019-02-14). To test that hypothesis, I made this change in the commit that commit, but all tests still passed. I think the case was necessary before then, we just didn't have tests for it. Differential Revision: https://phab.mercurial-scm.org/D6275
Wed, 17 Apr 2019 23:10:14 -0700 copies: document cases in _chain()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 17 Apr 2019 23:10:14 -0700] rev 42227
copies: document cases in _chain() Differential Revision: https://phab.mercurial-scm.org/D6274
Wed, 17 Apr 2019 14:44:18 -0700 copies: ignore heuristics copytracing when using changeset-centric algos
Martin von Zweigbergk <martinvonz@google.com> [Wed, 17 Apr 2019 14:44:18 -0700] rev 42226
copies: ignore heuristics copytracing when using changeset-centric algos Differential Revision: https://phab.mercurial-scm.org/D6269
Wed, 17 Apr 2019 14:42:23 -0700 copies: move check for experimental.copytrace==<falsy> earlier
Martin von Zweigbergk <martinvonz@google.com> [Wed, 17 Apr 2019 14:42:23 -0700] rev 42225
copies: move check for experimental.copytrace==<falsy> earlier I'm going to ignore experimental.copytrace when changeset-centric algorithms are required. This little refactoring makes that easier to add. Differential Revision: https://phab.mercurial-scm.org/D6268
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip