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.
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].
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.
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
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
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
copies: document cases in _chain()
Differential Revision: https://phab.mercurial-scm.org/D6274