fsmonitor can significantly speed up operations on large working
directories. But fsmonitor isn't enabled by default, so naive users
may not realize there is a potential to make Mercurial faster.
This commit introduces a warning to working directory updates when
fsmonitor could be used.
The following conditions must be met:
* Working directory is previously empty
* New working directory adds >= N files (currently 50,000)
* Running on Linux or MacOS
* fsmonitor not enabled
* Warning not disabled via config override
Because of the empty working directory restriction, most users will
only see this warning during `hg clone` (assuming very few users
actually do an `hg up null`).
The addition of a warning may be considered a BC change. However, clone
has printed warnings before. Until recently, Mercurial printed a warning
with the server's certificate fingerprint when it wasn't explicitly
trusted for example. The warning goes to stderr. So it shouldn't
interfere with scripts parsing meaningful output.
The OS restriction was on the advice of Facebook engineers, who only
feel confident with watchman's stability on the supported platforms.
.. feature::
Print warning when fsmonitor isn't being used on a large repository
Differential Revision: https://phab.mercurial-scm.org/D894
Since the ui objects can be created with the 'load' class method, it
is possible to lose the exit handlers information from the old ui instance. For
example, running 'test-bad-extension.t' leads to this situation where chg
creates a new ui instance which does not copy the exit handlers from the
earlier ui instance. For exit handlers, which are special cases anyways, it
probably makes sense to have a global state of the handlers. This would ensure
that the exit handlers registered once are definitely executed at the end of
the request.
Test Plan:
Ran all the tests without '--chg' option. This also fixes the
'test-bad-extension.t' with the '--chg' option.
Differential Revision: https://phab.mercurial-scm.org/D1166
Splitting at too small gaps might not be worthwhile. With this changeset,
we stop considering splitting on too small gaps. The threshold is configurable.
We arbitrarily pick 256K as a default value because it seems "okay".
Further testing on various repositories and setups will be needed to tune it.
The option name is 'experimental.sparse-read.min-gap-size`, and replaces
`experimental.sparse-read.min-block-size` which is not used any more.
The previous recursive approach was trying to optimise each read slice to have
a good density. It had the tendency to over-optimize smaller slices while
leaving larger hole in others.
The new approach focuses on improving the combined density of all the reads,
instead of the individual slices. It slices at the largest gaps first, as they
reduce the total amount of read data the most efficiently.
Another benefit of this approach is that we iterate over the delta chain only
once, reducing the overhead of slicing long delta chains.
On the repository we use for tests, the new approach shows similar or faster
performance than the current default linear full read.
The repository contains about 450,000 revisions with many concurrent
topological branches. Tests have been run on two versions of the repository:
one built with the current delta constraint, and the other with an unlimited
delta span (using 'experimental.maxdeltachainspan=0')
Below are timings for building 1% of all the revision in the manifest log using
'hg perfrevlogrevisions -m'. Times are given in seconds. They include the new
couple of follow-up changeset in this series.
delta-span standard unlimited
linear-read 922s 632s
sparse-read 814s 566s
I think there's a slight hole here in that a subrepo could be shared, removed
from .hgsub, and then it's not part of context.substate (so not iterated over).
But the push command has the same hole IIRC, and I think removing a subrepo is
an edge case.
The import hack is a copy/paste of subrepo.subrepo().
This will be used to setup unsharing subrepos. Usually cmdutil is used for
this purpose. But the implementation needs hg.copystore(), and the hg module
already imports cmdutil.
Before this changesets, a literal '.*:foo$' config would match a registered
'.*:foo$' generic. This is wrong since generic should be matched through
regular exception only. This changeset fixes this problem.
Thanks for to Yuya Nishihara for spotting the issue.
When the list of dates is empty, `min` and `max` would raises a ValueError.
Protect against this case by checking that the date list is not empty.
I didn't add a test because I couldn't find a reproducing test case.
Grouping all evolution related-config under the experimental.evolution
namespace would helps the future migration outside [experimental].
Differential Revision: https://phab.mercurial-scm.org/D1155
Stabilization config items were never part of a release, remove them now that
we cleaned up the evolution related configuration.
Differential Revision: https://phab.mercurial-scm.org/D1154
Update the evolution helpers function to support both old-style configuration and
new-style configuration:
experimental.evolution=all is renamed into experimental.evolution=true
experimental.evolution=createmarkers is renamed into
experimental.evolution.createmarkers=true
experimental.evolution=allowunstable is renamed into
experimental.evolution.allowunstable=true
experimental.evolution=exchange is renamed into
experimental.evolution.exchange=true
We choose to not rename individual config options; keeping the same names
would easy the transition for users but it's something that could be easily
done in the future.
Differential Revision: https://phab.mercurial-scm.org/D1147
We want to split the evolution-related configuration and back-out the renaming
from evolution.* to stabilization.*.
First invert the configuration and aliases, so next changesets will be
cleaner.
Differential Revision: https://phab.mercurial-scm.org/D1146
# skip-blame because parsers.c is mechanically rewritten by
clang-format with no semantic change.
Differential Revision: https://phab.mercurial-scm.org/D1170
This gives clang-format the right notion about formatting these struct
initializers, therefore allowing us to automatically format several
additional files.
# skip-blame because this is just a content-free comment addition
Differential Revision: https://phab.mercurial-scm.org/D1169
This new debugcommand prints the capabilities of any remote in a human friendly
way. Improved bundle2 capabilities support will be introduced in the next
changesets.
We seem to have settled down on behavior changes here (nothing
matching revset `keyword(revert) and keyword(interactive)` since 4.2
was released), so let's go ahead and advertise this excellent feature.
.. feature:: revert --interactive
The revert command now accepts the flag --interactive to allow reverting
only some of the changes to the specified files.
We want a slightly weird format here so that it's easier to read, but
in order to preserve that we need to disable clang-format.
Differential Revision: https://phab.mercurial-scm.org/D1168
Now that all known options are declared, we setup a warning to make sure it will
stay this way.
We disable the warning in two tests checking other behavior with random options.
We add an experimental -L/--line-range option to 'hg log' taking file patterns
along with a line range using the (new) FILE,FROMLINE-TOLINE syntax where FILE
may be a pattern (matching exactly one file). The resulting history is similar
to what the "followlines" revset except that, if --patch is specified,
only diff hunks within specified line range are shown.
Basically, this brings the CLI on par with what currently only exists in hgweb
through line selection in "file" and "annotate" views resulting in a file log
with filtered patch to only display followed line range.
The option may be specified multiple times and can be combined with --rev and
regular file patterns to further restrict revisions. Usage of this option
requires --follow; revisions are shown in descending order and renames are
followed. Only the --graph option is currently not supported.
The UI is the result of a consensus from review feedback at:
https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-October/106749.html
The implementation spreads between commands.log() and cmdutil module.
In commands.log(), the main loop may now use a "hunksfilter" factory (similar
to "filematcher") that, for a given "rev", produces a filtering function
for diff hunks for a given file context object.
The logic to build revisions from -L/--line-range options lives in
cmdutil.getloglinerangerevs() which produces "revs", "filematcher" and
"hunksfilter" information. Revisions obtained by following files' line range
are filtered if they do not match the revset specified by --rev option. If
regular FILE arguments are passed along with -L options, both filematchers are
combined into a new matcher.
.. feature::
Add an experimental -L/--line-range FILE,FROMLINE-TOLINE option to 'hg log'
command to follow the history of files by line range. In combination with
-p/--patch option, only diff hunks within specified line range will be
displayed. Feedback, especially on UX aspects, is welcome.
We add a 'hunksfilterfn' keyword argument in all functions of the call
stack from changeset_printer.show() to patch.diff(). This is a callable
that will be used to filter out hunks by line range and will be used in
the "-L/--line-range" option of "hg log" command introduced in the
following changesets.
We'll need the same logic in forthcoming changeset to handle --line-range
option in 'hg log' command.
The function lives in scmutil.py (rather than util.py) as it uses match and
pathutil modules.
Use the verbosity aware template keyword introduced earlier. It has the nice
property of being verbosity dependent but in order to customize the obsfate
part, users will need to replace the lobsfate definition from default mapfile
with the one using template functions (by copying the one from test-obsmarker-
template.t for example).
As it's a more advanced use-case, I'm more inclined to have the same code for
the {obsfate} keyword, in the changeset printer and in the default mapfile for
consistency.
But, the definition in default mapfile could be replaced with one based on
template filter to obsfate output customization if it is a big need for users.
Having an obsfate by default in log will be useful for users to understand why
they have obsolete and unstable changesets. Obsfate will only be shown for
obsolete changesets, which only happens if people opt-in to experimental feature.
But when obsolete changeset are visible, it is very useful to understand where
they are. Having it in log could be sufficient for most people, so they don't
have to learn a new command (like obslog which is itself useful in case of
divergences).
For example, when pulling and working directory parent become obsolete:
$ hg pull
...
working directory parent is obsolete! (f936c1697205)
This message comes from the Evolve extension.
Obsfate would comes handy:
$ hg log -G
o changeset: 2:6f91013c5136
| tag: tip
| parent: 0:4ef7b558f3ec
| user: Boris Feld <boris.feld@octobus.net>
| date: Mon Oct 09 16:00:27 2017 +0200
| summary: A
|
| @ changeset: 1:f936c1697205
|/ user: Boris Feld <boris.feld@octobus.net>
| date: Mon Oct 09 16:00:27 2017 +0200
| obsfate: rewritten using amend as 2:6f91013c5136
| summary: -A
|
o changeset: 0:feb4dd822b8c
user: Boris Feld <boris.feld@octobus.net>
date: Tue Oct 09 16:00:00 2017 +0200
summary: ROOT
And once we update, we don't have an obsolete changeset in the log anymore so
we don't show obsfate anymore, most users won't see obsfate often if they
don't have obsolete changeset often:
@ changeset: 2:6f91013c5136
| tag: tip
| parent: 0:4ef7b558f3ec
| user: Boris Feld <boris.feld@octobus.net>
| date: Mon Oct 09 16:00:27 2017 +0200
| summary: A
|
o changeset: 0:feb4dd822b8c
user: Boris Feld <boris.feld@octobus.net>
date: Tue Oct 09 16:00:00 2017 +0200
summary: ROOT
Obsolescence is sometimes used only locally so the obs-marker users is always
the same. Showing the user in this case does not bring much values.
In the case where multiple users rewrite the commit, display the full list of
users. Also show all users in verbose mode.
Introduce an obsfate printer that uses all helpers functions defined in
obsutil to get all the obsfate-related data and format a string according to
the current format in test-obsmarker-template.t.
Then, introduce an obsfate templatekw that uses the obsfateprinter to return a
list of strings.
The goal is not to replace existing obsfate template functions but to propose
a default, good-enough and easily usable obsfate definition for end-users that
don't want to customize it. Such output would ultimately get included in the
default log output.
Here are some output examples for a commit amended:
rewritten using amend as 5:a9b1f8652753 by test (at 1970-01-01 00:00 +0000)
Next patches will make the output dependent on the verbosity.
Exemple of use-cases:
For having the obsfate on a single-line between brackets:
{if(obsfate, " [{join(obsfate, "; ")}]")}
For having the obsfate in several lines:
{if(obsfate, "{obsfate % " Obsfate: {fate}\n"}")}
The heuristics algorithm find possible candidates for move/copy and then check
whether they are actually a copy or move. In some cases, there can be lot of
candidates possible which can actually slow down the algorithm.
This patch introduces a config option
`experimental.copytrace.movecandidateslimit` using which one can limit the
candidates to check. The limit defaults to 100.
Thanks to Yuya for suggesting to skip copytracing for that file with a
warning.
Differential Revision: https://phab.mercurial-scm.org/D987
I have spent a lot of time debugging extensions that failed to load
because we don't include a traceback and I didn't realize I could get
traceback for the extension failure with --traceback. Let's just turn
them on by default, since it should be rare that the user sees these
tracebacks anyway (and if they do, it's not so bad if the extra
traceback pushes them a little harder to report the problem).
Since we already had a test case with --traceback and one without, I
just removed the one with the flag.
Differential Revision: https://phab.mercurial-scm.org/D1164
The show extension reads `commands.show.aliasprefix` config in its
`extsetup` and that causes issues with chg. This patch adds that config item
to chg confighash to solve the issue.
Test Plan:
`run-tests.py -l --chg test-show.t`
Differential Revision: https://phab.mercurial-scm.org/D1158
We only want to do I/O in terms of bytes, so lets explode early
instead of recursing forever.
Differential Revision: https://phab.mercurial-scm.org/D1136
The part we are using for pull is now used for push too. As we no longer use
pushkey, pushkey hooks are no longer triggered. This is an obvious backward
incompatible change. We could artificially trigger the pushkey hook within the
bundle2 part, but this seemed too hacky to me.
An option would be to disable by default this new mechanism for a couple of
versions to help people migrate to `txnclose-phase`. I took the liberal and
optimistic path to just turn it on by default directly.
.. bc::
Push no longer triggers a pushkey hook when updating phases. Use the new
`txnclose-phase` and `txnclose-phase` hooks instead.
(Applies when both server and client use version 4.4 or above).
`filecmp` follows symlinks by default, which a `filectx.cmp()` call should not
be doing as it should only compare the requested entry. After this patch, only
the contexts' data are compared, which is the correct contract.
This is a corrected version of D1122.
Differential Revision: https://phab.mercurial-scm.org/D1165
Fix regression introduced in D785.
In some circumstances, context.clearunknown can be called before the path is
audited. Audit the path before deleting any conflicting files.
Differential Revision: https://phab.mercurial-scm.org/D1157
The shelve extensions import and call rebase content without loading the
extension. This is problematic as the config items rebase uses are not
declared and the default value are not set, etc...
The shelve extension should be using core utilities only and the necessary bit
should be moved from rebase into core. In the meantime, I'm taking a small
step to get config registration completed with minimal overhead. The rebase
extension is shipped with core so registering its config option within core is
not a big issue.
This is the last step needed before we can install a warning that enforces all
config to be registered.
We register the merge-tools config section (which has an arbitrary base config
value) and the possible sub-attribute. The sub-attribute has to be registered
first or at the same time otherwise the '.*' item would shadow them.
Merge tools could include "." in their name so we can't constrain any more
than just ".*".
Delta chains can become quite sparse if there is a lot of unrelated data between
relevant pieces. Right now, revlog always reads all the necessary data for the
delta chain in one single read. This can lead to a lot of unrelated data to be
read (see issue5482 for more details).
One can use the `experimental.maxdeltachainspan` option with a large value
(or -1) to easily produce a very sparse delta chain.
This change introduces the ability to slice the chunks retrieval into multiple
reads, skipping large sections of unrelated data. Preliminary testing shows
interesting results. For example the peak memory consumption to read a manifest
on a large repository is reduced from 600MB to 250MB (200MB without
maxdeltachainspan). However, the slicing itself and the multiple reads can have
an negative impact on performance. This is why the new feature is hidden behind
an experimental flag.
Future changesets will add various parameters to control the slicing heuristics.
We hope to experiment a wide variety of repositories during 4.4 and hopefully
turn the feature on by default in 4.5.
As a first try, the algorithm itself is prone to deep changes. However, we wish
to define APIs and have a baseline to work on.
When a merge commit creates an empty diff in the revlog, its offset may still
be quite far from the end of the previous chunk.
Skipping these empty chunks may reduce read size significantly.
In most cases, there is no gain, and in some cases, little gain.
On my clone of pypy, `hg manifest` reads 65% less bytes (96140 i/o 275943) for
revision 4260 by ignoring the only empty trailing diff.
For revision 2229, 35% (34557 i/o 53435)
Sadly, this is difficult to reproduce, as hg clone can make its own different
structure every time.
Move the logic to build bundle2 pushkey part into its dedicated function. It
will help to keep the logic clear when adding support for sending phases change
using 'phase-heads' part.
We are about to switch phase pushing from using pushkey to using a the new
dedicated binary part. We introduce the push race detection on its own to help
detect potential impact.
This part checks if revisions are still in the same phase as when the
bundle was generated. This is similar to what 'check:heads' or
'check:updated-heads' bundle2 part achieves for changesets.
We needs seems before we can move away from pushkey usage from phase since
pushkey has it own built-in push-race detection.
This comment is about:
issue3781: Courtesy Phases synchronisation to publishing server prevent
subrepo push
Not about:
issue3871: Slow hg log when template contains {file_adds}, {file_mods} and
{file_dels}
The on-disk file can contain draft root that are descendants of secret root.
The resulting phase computation is correct, but the phases root content is
not. I will send another series to introduce code that remove some of the
cases where this can happens, but we first need to damage control the existing
case.
After this changeset, we can no longer advertise secret changeset as draft
root.
Previously, only the top level repo was shared, and then any subrepos were
cloned on demand. This is problematic because commits to the parent repo would
write an updated .hgsubstate to the share source, but the corresponding subrepo
commit would be stuck in the local subrepo. That would prevent an update in the
source repo. We already go to great lengths to avoid having inconsistent repos
(e.g., `hg push -r rev` will push _everything_ in a subrepo, even if it isn't
referenced in one of the parent's outgoing commits). Therefore, this seems like
a bug fix, and there's no option to get the old behavior. I can't imagine the
previous behavior was useful to anybody.
There shouldn't be an issue with svn, since it is centralized. Maybe --git-dir
can be used for git subrepos, but I'll leave that to someone more familiar with
git.
An integer was previously being implicitly returned from commands.share(), which
caused dispatch() to start crashing when changing over to returning the shared
repo. All error paths appear to raise, so this can be hardcoded to success.
The clone command checks for 'is None' in a similar pattern, but since
hg.clone() always returns a tuple, that seems wrong?
.. fix:: Issue 5675
Creating a share of a repository with a Mercurial subrepository will now
share the subrepository.
and
.. bc::
Mercurial subrepositories are now shared instead of cloned when the parent
repository is shared. This prevents dangling subrepository references in the
share source. Previously shared repositories with cloned subrepositories
will continue to function unchanged.
__name__ is unicode, but we need bytes. For now, we'll make the
(mostly-safe) assumption that template filter names will be ascii.
Differential Revision: https://phab.mercurial-scm.org/D1137
Stops us from choking the templater on Python 3. With this patch
applied, much of hgweb works correctly in Python 3. The notable
exception is the graph page, which chokes because it gets node IDs as
str instead of bytes.
Differential Revision: https://phab.mercurial-scm.org/D1135
experimental.updatecheck was renamed into commands.update.check, use the
config system to provides the fallback on the old config name instead of
adding more code.
Differential Revision: https://phab.mercurial-scm.org/D1117
I may be a weird person for liking this style, but our C style is
historically nominally the Linux Kernel style, and when you configure
clang-format to be kernel-ish, this is what you get. If we want to
change it, we can do so by tweaking the formatter rules in the future.
Differential Revision: https://phab.mercurial-scm.org/D1132
Depends on D932.
Call the new _onfilemergefailure function when a merge tool reports failure
via a return code.
Differential Revision: https://phab.mercurial-scm.org/D951
Depends on D931.
This patch introduces functions and a config option that will allow a user
to halt the merge if there are failures during a file merge. These functions
will be used in the next patch.
Differential Revision: https://phab.mercurial-scm.org/D932
`commit --amend` and amend command in core and extensions rely on
cmdutil.amend() for amending a commit. So the logic to add a note to amend must
reside here. This patch assumes that note will be passed in opts dictionary to
the function and it will be passed to cleanupnodes and then createmarkers to
store the note in the obsmarker metadata.
After this patch, note can be stored on an amend changeset by passing notes as a
part of opts to cmdutil.amend().
Differential Revision: https://phab.mercurial-scm.org/D1094
This patch adds a metadata argument to cleanupnodes() which will be dict and can
be passed to obsmarker.createmarkers() and can be stored on the obsmarker.
In cases when obsolescence is not enabled, the metadata argument is useless.
This is a step towards storing a note in amend.
Differential Revision: https://phab.mercurial-scm.org/D1093
With in-memory merge, copy information needs to be stored in-memory, not in the
dirstate.
To make this transition easy, move the existing dirstate-based approach to
workingfilectx; that way, other implementations can choose to store it
somewhere else.
Differential Revision: https://phab.mercurial-scm.org/D1106
With in-memory merge, backup files might be overlayworkingfilectxs stored
in memory. But they could also be real files if the user's backup directory is
outside the working dir.
Rather than have two code paths everywhere, let's use arbitraryfilectx so they
can be consistent.
Differential Revision: https://phab.mercurial-scm.org/D1057
This patch adds support for storing the type of command which is going to run in
the func object. For this it does the following:
1) Add three possible values as attributes to the registrar.command class
2) Add a new argument to registrar.command._doregister function
3) Add a new attribute cmdtype to the func object
The type of command will be helpful in deciding what level of access on hidden
commits it can has.
Differential Revision: https://phab.mercurial-scm.org/D736
That's more in line with what we want, and we know it's ASCII data
since that's all HTTP technically allows in headers anyway.
Differential Revision: https://phab.mercurial-scm.org/D1112
Rename 'devel.empty-changegroup' to 'devel.warn-empty- changegroup' in order
to clarify it controls a warning message.
No alias is installed since the previous configuration option was not
documented.
The latter returns a generator object on Python 3, which breaks
various parts of hg that expected a list.
Differential Revision: https://phab.mercurial-scm.org/D1100
In Python 3, the map() returns a generator object instead of a list,
and some parts of hg depend on this being consumable more than once or
sortable in place.
Differential Revision: https://phab.mercurial-scm.org/D1099
This will explode violently if we have a non-ascii command name. That
shouldn't ever happen in core, and seems unlikely even in third-party
code. Regardless, it'll explode violently, so we can revisit things in
the future if we need to change the encoding here.
Differential Revision: https://phab.mercurial-scm.org/D1092
Without this if branch, we infinitely recurse in _flatten, which is
very confusing. Something in an hgweb template is trying to write out
a string instead of a bytes on Python 3, and this at least makes it
crash politely.
Differential Revision: https://phab.mercurial-scm.org/D1088
While doing Python 3 porting work, I've seen exceptions happen in
parts of hgweb we normally assume are robust. It won't hurt anything
to set this attribute significantly earlier, so let's do so and save
confusing during the porting process.
Differential Revision: https://phab.mercurial-scm.org/D1085
This allows us to %include map-cmdline.<style> file in our .hgrc files. The
syntax is slightly different as hgrc doesn't support loading an external
template file, but map-cmdline files don't use this feature, so the syntax
can be considered identical in practice.
Unnamed section is remapped for backward compatibility.
The new 'txnclose-phase' hook expose the phase movement information stored in
'tr.changes['phases]'. To provide a simple and straightforward hook API to the
users, we introduce a new hook called for each revision affected. Since a
transaction can affect the phase of multiple changesets, updating the existing
'txnclose' hook to expose that information would be more complex. The data for
all moves will not fit in environment variables and iterations over each move
would be cumbersome. So the introduction of a new dedicated hook is
preferred in this changesets.
This does not exclude the addition of the full phase movement information to
the existing 'txnclose' in the future to help write more complex hooks.
The new 'txnclose-bookmark' hook expose the bookmark movement information
stored in 'tr.changes['bookmarks]'. To provide a simple and straightforward
hook API to the users, we introduce a new hook called for each bookmark
touched. Since a transaction can affect multiple bookmarks, updating the
existing 'txnclose' hook to expose that information would be more complex. The
data for all moves might not fit in environment variables and iterations over
each move would be cumbersome. So the introduction of a new dedicated hook is
preferred in this changeset.
This does not exclude the addition to the full bookmark information to the
existing 'txnclose' in the future to help write more complex hooks.
This is the second-safest option we have to offer in `updatecheck`,
with `abort` being the safest and `linear` being the default. At the
sprint we discussed how much `none` and `linear` make us all
uncomfortable, and how we'd like to move the default behavior if we can.
I'm not sure we can get away with actually changing the out of the box
default behavior, but we can at *least* do this.
Differential Revision: https://phab.mercurial-scm.org/D1062
Kind of a tangled mess, but now logging works in both Python 2 and 3.
# no-check-commit because of the interface required by Python's HTTP
server code.
Differential Revision: https://phab.mercurial-scm.org/D1080
.. feature::
New `commands.update.check` feature to adjust constraints on when
`hg update` will allow updates with a dirty working copy.
also
.. bc::
The `experimental.updatecheck` name for the new `commands.update.check`
feature is now deprecated, and will be removed after this release.
Differential Revision: https://phab.mercurial-scm.org/D1070
Just easier to muddle through for my brain now that I don't see the
old pattern much anymore.
Differential Revision: https://phab.mercurial-scm.org/D1077
On Python 3, we need to use unicodes, rather than bytes. This lets
test-pull.t get a lot further along.
Differential Revision: https://phab.mercurial-scm.org/D887
Follow-up on refactorings 6a96abee0045 and b8c13fc92233 of the original
changeset 8c58ee1e5fa4 by updating the docstrings of dirnode class and tersedir
function:
* rewrite dirnode.iterfilepaths()'s docstring (the method got
renamed and reimplemented in b8c13fc92233);
* simplify and update dirnode.tersewalk() to remove reference to 'self' and
'tersedict';
* use the imperative form of verbs in the first sentence of all docstrings.
Differential Revision: https://phab.mercurial-scm.org/D1072
Previously reviewed as D964, but required some fixups and therefore
seems to need a new revision.
Differential Revision: https://phab.mercurial-scm.org/D1065
Preparing the data for some hooks can be expensive. Add a function to check if
a hook exists so we can skip useless preparation if no hook is configured.
Turn dirnode's methods into generators which can be used to update "tersedict"
in caller. So instead of passing the "tersedict" to be mutated here and there,
it's now clearer where it is updated as it's purely a local variable to
tersedir() function.
While I was here, I renamed _processtersestatus to tersewalk and
_addfilestotersed to iterfilepaths.
Differential Revision: https://phab.mercurial-scm.org/D1043
The previous terse status implementation was hacking around os.listdir() and was
flaky. There have been a lot of instances of mercurial buildbots failing
and google's internal builds failing because of the
hacky implementation of terse status. Even though I wrote the last
implementation but it was hard for me to find the reason for the flake.
The new implementation can be slower than the old one but is clean and easy to
understand.
In this we create a node object for each directory and create a tree
like structure starting from the root of the working copy. While building the
tree like structure we store some information on the nodes which will be helpful
for deciding later whether we can terse the dir or not.
Once the whole tree is build we traverse and built the list of files for each
status with required tersing.
There is no behaviour change as the old test, test-status-terse.t passes with
the new implementation.
Differential Revision: https://phab.mercurial-scm.org/D985
In future patches, we may halt the merge process based on configuration or
user requests by raising exceptions. We need to ensure that the mergestate
is unconditionally committed even when such an exception is raised.
Depends on D930.
Differential Revision: https://phab.mercurial-scm.org/D931
Now that dirstatemap is the source of truth for the list of directories, let's
move _dirfoldmap on to it.
This pattern of moving cached variables onto the dirstate map makes it easier to
invalidate them, as seen by how the cache invalidation functions are slowly
shrinking to just be recreating the dirstatemap instance.
Differential Revision: https://phab.mercurial-scm.org/D983
Now that dirs is source of truthed on the dirstatemap, let's get rid of the
_dirs propertycache on the dirstate.
Differential Revision: https://phab.mercurial-scm.org/D982
Now that the filefoldmap is source of truthed on the dirstatemap, let's get rid
of the property cache on the dirstate.
Differential Revision: https://phab.mercurial-scm.org/D981
Moving the identity function to the dirstatemap class will allow alternative
dirstate implementations to replace the implementation.
Differential Revision: https://phab.mercurial-scm.org/D980
As part of separating dirstate business logic from storage, let's move the
nonnormal and otherparent storage to the dirstatemap class. This will allow
alternative dirstate storage to persist these sets instead of recomputing them.
Differential Revision: https://phab.mercurial-scm.org/D979
As part of separating the dirstate business logic from the dirstate storage
logic, let's move the serialization code down into dirstatemap.
Differential Revision: https://phab.mercurial-scm.org/D978
As part of separating the dirstate business logic from the storage, let's move
the read code into the new dirstatemap class.
Differential Revision: https://phab.mercurial-scm.org/D977
