Yuya Nishihara <yuya@tcha.org> [Tue, 25 Oct 2016 21:49:30 +0900] rev 30232
templater: use unfiltered changelog to calculate shortest() at constant time
cl._partialmatch() can be pretty slow if hidden revisions are involved. This
patch cancels the slowdown introduced by the previous patch by using an
unfiltered changelog, which means shortest(node) isn't always the shortest.
The result isn't perfect, but seems okay as long as shortest(node) is short
enough to type and can be used as an identifier.
(with hidden revisions)
% hg log -R hg-committed -r0:20000 -T '{node|shortest}\n' --time > /dev/null
(.^^) time: real 1.530 secs (user 1.480+0.000 sys 0.040+0.000)
(.^) time: real 43.080 secs (user 43.060+0.000 sys 0.030+0.000)
(.) time: real 1.680 secs (user 1.650+0.000 sys 0.020+0.000)
Yuya Nishihara <yuya@tcha.org> [Sun, 23 Oct 2016 14:05:23 +0900] rev 30231
templater: do not use index.partialmatch() directly to calculate shortest()
cl.index.partialmatch() isn't a drop-in replacement for cl._partialmatch().
It has no knowledge about hidden revisions, and it raises ValueError if a node
shorter than 4 chars is given. Instead, use index.partialmatch() through
cl._partialmatch(), which has no such problems and gives the identical result
with/without --pure.
The test output was sampled with --pure without this patch, which shows the
most correct result. However, we'll need to switch to using an unfiltered
changelog because _partialmatch() of a filtered changelog can be an order of
magnitude slower.
(with hidden revisions)
% hg log -R hg-committed -r0:20000 -T '{node|shortest}\n' --time > /dev/null
(.^) time: real 1.530 secs (user 1.480+0.000 sys 0.040+0.000)
(.) time: real 43.080 secs (user 43.060+0.000 sys 0.030+0.000)
Yuya Nishihara <yuya@tcha.org> [Wed, 26 Oct 2016 22:50:06 +0900] rev 30230
tests: run "cwd was removed" test only if cwd can actually be removed
On some platforms, cwd can't be removed. In which case, util.unlinkpath()
continues with no error since the failure of directory removal isn't critical.
So it doesn't make sense to run the test added by
90a6c18a7c1d on those
platforms. OTOH, we need to run the test in test-rebase-scenario-global.t
since the repository is referenced after that.
Gábor Stefanik <gabor.stefanik@nng.com> [Tue, 25 Oct 2016 21:01:53 +0200] rev 30229
merge: avoid superfluous filemerges when grafting through renames (
issue5407)
This is a fix for a regression introduced by the patches for
issue4028.
The test changes are due to us doing fewer _checkcopies searches now, which
makes some test outputs revert to the pre-
issue4028 behavior. That issue itself
remains fixed, we only skip copy tracing for files where it isn't relevant.
As a nice side effect, this makes copy detection much faster when tracing
backwards through lots of renames.
Gábor Stefanik <gabor.stefanik@nng.com> [Wed, 19 Oct 2016 18:06:14 +0200] rev 30228
sslutil: guard against broken certifi installations (
issue5406)
Certifi is currently incompatible with py2exe; the Python code for certifi gets
included in library.zip, but not the cacert.pem file - and even if it were
included, SSLContext can't load a cacert.pem file from library.zip.
This currently makes it impossible to build a standalone Windows version of
Mercurial.
Guard against this, and possibly other situations where a module with the name
"certifi" exists, but is not usable.
Mads Kiilerich <madski@unity3d.com> [Tue, 25 Oct 2016 18:56:27 +0200] rev 30227
revset: don't cache abstractsmartset min/max invocations infinitely
There was a "leak", apparently introduced in
ab66c1dee405. When running:
hg = hglib.open('repo')
while True:
hg.log("max(branch('default'))")
all filteredset instances from branch() would be cached indefinitely by the
@util.cachefunc annotation on the max() implementation.
util.cachefunc seems dangerous as method decorator and is barely used elsewhere
in the code base. Instead, just open code caching by having the min/max
methods replace themselves with a plain lambda returning the result.
Kevin Bullock <kbullock+mercurial@ringworld.org> [Mon, 24 Oct 2016 09:14:34 -0500] rev 30226
merge with i18n
Wagner Bruna <wbruna@yahoo.com> [Sat, 22 Oct 2016 23:18:43 -0200] rev 30225
i18n-pt_BR: synchronized with
7b428b00a1d4
Mads Kiilerich <madski@unity3d.com> [Tue, 18 Oct 2016 16:52:35 +0200] rev 30224
dirstate: fix debug.dirstate.delaywrite to use the new "now" after sleeping
It seems like the a regression has sneaked into debug.dirstate.delaywrite in
6c6b48aca328. It would sleep until no files were modified "now" any more, but
when writing the dirstate it would use the old "now" and still mark files as
'unset' instead of recording the timestamp that would make the file show up as
clean instead of unknown.
Instead of getting a new "now" from the file system, we trust the computed end
time as the new "now" and thus cause the actual modification time to be
writiten to the dirstate.
debug.dirstate.delaywrite is undocumented and only used in
test-largefiles-update.t . All tests seems to work fine for me without
debug.dirstate.delaywrite . Perhaps because it not really worked as intended
without the fix in this patch, and code and tests thus have evolved to do fine
without it? It could thus perhaps make sense to drop usage of this setting in
the tests. That could speed the test up a bit.
This functionality (or something very similar) can however apparently be very
convenient in setups where checking dirty-ness is expensive - such as when
using large files and have slow file filesystems or are CPU constrained. Now it
works and we can try it. (But ideally, for the largefile use case, it should
probably only delay lfdirstate writes - not ordinary dirstate.)
Simon Farnsworth <simonfar@fb.com> [Fri, 21 Oct 2016 16:31:16 +0100] rev 30223
tests: fix test-casefolding.t
The message had changed, but the test was not updated. This test does not
run on Linux, but failed on my Mac.
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 19 Oct 2016 15:07:11 -0700] rev 30222
commands: print security protocol support in debuginstall
Over the past week I've had to instruct multiple people to run
Python code to query the ssl module to see what TLS protocol support
is present. I think it would be useful for `hg debuginstall` to print
this info to make it easier to access and debug why Mercurial is
complaining about using an insecure TLS 1.0 protocol.
Ideally we'd also print the path to the CA cert bundle. But the APIs
for querying that in sslutil can emit warnings, making it slightly
more difficult to integrate into `hg debuginstall`. That work will
have to wait for another day.
Durham Goode <durham@fb.com> [Tue, 18 Oct 2016 17:44:42 -0700] rev 30221
manifest: make treemanifestctx store the repo
Same as in the last commit, the old treemanifestctx stored a reference to the
revlog. If the inmemory revlog became invalid, the ctx now held an old copy and
would be incorrect. To fix this, we need the ctx to go through the manifestlog
for each access.
This is the same pattern that changectx already uses (it stores the repo, and
accesses commit data through self._repo.changelog).
Durham Goode <durham@fb.com> [Tue, 18 Oct 2016 17:44:26 -0700] rev 30220
manifest: make manifestctx store the repo
The old manifestctx stored a reference to the revlog. If the inmemory revlog
became invalid, the ctx now held an old copy and would be incorrect. To fix
this, we need the ctx to go through the manifestlog for each access.
This is the same pattern that changectx already uses (it stores the repo, and
accesses commit data through self._repo.changelog).
Durham Goode <durham@fb.com> [Tue, 18 Oct 2016 17:33:39 -0700] rev 30219
manifest: make manifestlog a storecache
The old @property on manifestlog was broken. It meant that we would always
recreate the manifestlog instance, which meant the cache was never hit. Since
we'll eventually remove repo.manifest and make manifestlog the only property,
let's go ahead and make manifestlog the @storecache property, have manifestlog
own the manifest instance, and have repo.manifest refer to it via manifestlog.
This means all accesses go through repo.manifestlog, which is now invalidated
correctly.
Durham Goode <durham@fb.com> [Tue, 18 Oct 2016 17:32:51 -0700] rev 30218
manifest: move manifest creation to a helper function
A future patch will be moving manifest creation to be inside manifestlog as part
of improving our cache guarantees. bundlerepo and unionrepo currently rely on
being able to hook into manifest creation, so let's temporarily move the actual
manifest creation to a helper function for them to intercept.
In the future manifest.manifest() will disappear entirely and this can
disappear.
Kevin Bullock <kbullock@ringworld.org> [Tue, 18 Oct 2016 14:27:30 -0500] rev 30217
Added signature for changeset
438173c41587