os.path.relpath() exploded if the 'root' and 'cwd' directories had different
drive letters. I noticed this in TortoiseHg when typing a fileset into the
filter, and it kept complaining until the closing '()' was typed. This was
reproducible on the command line with:
$ cd /d
$ hg -R /c/Users/Matt/Projects/hg files 'set:e'
Traceback (most recent call last):
...
File "mercurial\pathutil.pyc", line 182, in canonpath
File "ntpath.pyc", line 529, in relpath
ValueError: path is on drive c:, start on drive d:
The original condition was a bit harsh for extension authors since third-party
extensions need to preserve compatibility with older Mercurial versions, where
no defaults would be loaded from the configtable. So let's silence the warning
if the given default value matches, which should be harmless.
After a refactoring, _toolstr stopped having default="" as one of it's args,
therefore when called without a default it returns None and not "". This causes
concatenation to fail.
We've found a severe perf regression in `hg update` caused by the path conflict
checking code. The next patch will disable this by default.
Differential Revision: https://phab.mercurial-scm.org/D1222
When a dirstate backup is restored, it is possible that no actual changes to
the dirstate have been made. In this case, the backup is still a hardlink
to the original dirstate.
Unfortunately, `os.rename` silently fails (nothing happens, and no error
occurs) when `src` and `dst` are hardlinks to the same file. As a result,
the backup is left lying around. Over time, these files accumulate.
When restoring dirstate backups, check if the backup and the dirstate are
the same file, and if so, just delete the backup.
Differential Revision: https://phab.mercurial-scm.org/D1201
A recent refactor added a layer of abstraction to the dirstate which makes doing
things like 'foo in dirstate' now require some extra Python attribute lookups.
This is causing a 100ms slow down in hg status for mozilla-central.
The fix is to hoist the inner dict's functions onto the main class once the lazy
loading it complete, as well as store the actual functions before doing the
status loop (as is done for other such functions).
In my testing, it seems to address the performance regression, but we'll
need to see the perf run results to know for sure.
Differential Revision: https://phab.mercurial-scm.org/D1257
Before the recent refactor, we would not load the entire map until it was
accessed. As part of the refactor, that got lost and even just trying to load
the dirstate parents would load the whole map. This caused a perf regression
(issue5713) and a regression with static http serving (issue5717).
Making it lazy loaded again fixes both.
Differential Revision: https://phab.mercurial-scm.org/D1253
A future diff will move the lazy loading aspect of dirstate to the dirstatemap
class. This means it requires a slightly different strategy of clearing than
just reinstantiating the object (since just reinstantiating the object will
lazily load the on disk data again later instead of remaining permanently
empty).
So let's give it it's own clear function.
Differential Revision: https://phab.mercurial-scm.org/D1252
The same applies to '?' if --quiet is used (or any of the other states if some
of -marduic is specified), but I couldn't figure out how to express that
clearly.
This seems a bit hacky, but works well. There should be no reason that
static-http repo had to load dirstate.
Initially I tried to proxy os.stat() call through vfs so that statichttpvfs
could hook it, but there wasn't a good error value which the statichttpvfs
could return to get around the util.filestat issue.
The short options "-c" and "-C" may be confusing for a novice reading the
documentation. Let's try to be more explicit, also mentioning the equivalent
long options ("--check" and "--clean") in the comments.
Currently, specifying both a line-range pattern and a bare file pattern
results in an AND operation whereas we probably want an OR so that bare file
patterns are like a line-range pattern with all lines specified.
So, until this works as expected, we disable this.
When a file is binary patch.trydiff() would yield None for 'hunkrange'. Handle
this case in the hunksfilter() callback.
Add tests with and without diff.git option as binary handling differs
depending on this option's value.
Effect-flags config was in flight while the previous evolve config renaming
was written. Now that both landed, gather effect-flags in
experimental.evolution like the others evolve-related configurations.
Differential Revision: https://phab.mercurial-scm.org/D1197
Yuja's comment on the original obsfate about how we would translate obsfate
and the recent discussions about exposing users to new concepts and names lead
have led me to think that 'obsfate' should be treated as internal jargon. End-
users should not be aware of obsfate, so we replace 'obsfate' by 'obsolete' in
changeset_printer.
It will be easier to understand for end-users, easier to translate and closer
to the original Evolve obsfate output.
I'm aware it's extremely late in the cycle but I think it's an UX improvement
for the end-users.
Differential Revision: https://phab.mercurial-scm.org/D1189
An empty entry in the revlog may happen for two reasons:
- when the file is empty, and the revlog stores a snapshot;
- when there is a merge and both parents were identical.
`hg debugindex -m | awk '$3=="0"{print}' | wc -l` gives 1917 of such entries
in my clone of pypy, and 113 on my clone of mercurial.
These empty revision may be located at the end of a sparse chain, and in some
special cases may lead to read relatively large amounts of data for nothing.
chgserver.py is also checking the config and will get:
devel-warn: accessing unregistered config item:
'commands.show.aliasprefix' at:
mercurial/chgserver.py:109
if the config is not registered.
Differential Revision: https://phab.mercurial-scm.org/D1178
When `$CHGHG` is set, `$HG` is ignored by the chg client. Removing it from
chg's sensitive environment list would avoid starting up servers
unnecessarily when `$CHGHG` is the same while `$HG` is different.
Differential Revision: https://phab.mercurial-scm.org/D1177
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.
