Sun, 23 Oct 2016 14:05:23 +0900 templater: do not use index.partialmatch() directly to calculate shortest() stable
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)
Wed, 26 Oct 2016 22:50:06 +0900 tests: run "cwd was removed" test only if cwd can actually be removed stable
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.
Tue, 25 Oct 2016 21:01:53 +0200 merge: avoid superfluous filemerges when grafting through renames (issue5407) stable
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.
Wed, 19 Oct 2016 18:06:14 +0200 sslutil: guard against broken certifi installations (issue5406) stable
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.
Tue, 25 Oct 2016 18:56:27 +0200 revset: don't cache abstractsmartset min/max invocations infinitely stable
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.
Mon, 24 Oct 2016 09:14:34 -0500 merge with i18n stable
Kevin Bullock <kbullock+mercurial@ringworld.org> [Mon, 24 Oct 2016 09:14:34 -0500] rev 30226
merge with i18n
Sat, 22 Oct 2016 23:18:43 -0200 i18n-pt_BR: synchronized with 7b428b00a1d4 stable
Wagner Bruna <wbruna@yahoo.com> [Sat, 22 Oct 2016 23:18:43 -0200] rev 30225
i18n-pt_BR: synchronized with 7b428b00a1d4
Tue, 18 Oct 2016 16:52:35 +0200 dirstate: fix debug.dirstate.delaywrite to use the new "now" after sleeping stable
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.)
Fri, 21 Oct 2016 16:31:16 +0100 tests: fix test-casefolding.t stable
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.
Wed, 19 Oct 2016 15:07:11 -0700 commands: print security protocol support in debuginstall stable
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.
Tue, 18 Oct 2016 17:44:42 -0700 manifest: make treemanifestctx store the repo stable
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).
Tue, 18 Oct 2016 17:44:26 -0700 manifest: make manifestctx store the repo stable
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).
Tue, 18 Oct 2016 17:33:39 -0700 manifest: make manifestlog a storecache stable
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.
Tue, 18 Oct 2016 17:32:51 -0700 manifest: move manifest creation to a helper function stable
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.
Tue, 18 Oct 2016 14:27:30 -0500 Added signature for changeset 438173c41587 stable
Kevin Bullock <kbullock@ringworld.org> [Tue, 18 Oct 2016 14:27:30 -0500] rev 30217
Added signature for changeset 438173c41587
Tue, 18 Oct 2016 14:27:25 -0500 Added tag 4.0-rc for changeset 438173c41587 stable
Kevin Bullock <kbullock@ringworld.org> [Tue, 18 Oct 2016 14:27:25 -0500] rev 30216
Added tag 4.0-rc for changeset 438173c41587
Tue, 18 Oct 2016 14:15:15 -0500 merge default into stable for 4.0 code freeze stable 4.0-rc
Kevin Bullock <kbullock+mercurial@ringworld.org> [Tue, 18 Oct 2016 14:15:15 -0500] rev 30215
merge default into stable for 4.0 code freeze
Tue, 18 Oct 2016 14:13:06 -0500 merge with i18n stable
Kevin Bullock <kbullock+mercurial@ringworld.org> [Tue, 18 Oct 2016 14:13:06 -0500] rev 30214
merge with i18n
Tue, 11 Oct 2016 20:39:47 -0300 i18n-pt_BR: synchronized with 149433e68974 stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Tue, 11 Oct 2016 20:39:47 -0300] rev 30213
i18n-pt_BR: synchronized with 149433e68974
Sun, 16 Oct 2016 13:35:23 -0700 changegroup: increase write buffer size to 128k
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 16 Oct 2016 13:35:23 -0700] rev 30212
changegroup: increase write buffer size to 128k By default, Python defers to the operating system for choosing the default buffer size on opened files. On my Linux machine, the default is 4k, which is really small for 2016. This patch bumps the write buffer size when writing changegroups/bundles to 128k. This matches the 128k read buffer we already use on revlogs. It's worth noting that this only impacts when writing to an explicit file (such as during `hg bundle`). Buffers when writing to bundle files via the repo vfs or to a temporary file are not impacted. When producing a none-v2 bundle file of the mozilla-unified repository, this change caused the number of write() system calls to drop from 952,449 to 29,788. After this change, the most frequent system calls are fstat(), read(), lseek(), and open(). There were 2,523,672 system calls after this patch (so a net decrease of ~950k is statistically significant). This change shows no performance change on my system. But I have a high-end system with a fast SSD. It is quite possible this change will have a significant impact on network file systems, where extra network round trips due to excessive I/O system calls could introduce significant latency.
Fri, 14 Oct 2016 01:31:11 +0200 changegroup: skip delta when the underlying revlog do not use them
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 14 Oct 2016 01:31:11 +0200] rev 30211
changegroup: skip delta when the underlying revlog do not use them Revlog can now be configured to store full snapshot only. This is used on the changelog. However, the changegroup packing was still recomputing deltas to be sent over the wire. We now just reuse the full snapshot directly in this case, skipping delta computation. This provides use with a large speed up(-30%): # perfchangegroupchangelog on mercurial ! wall 2.010326 comb 2.020000 user 2.000000 sys 0.020000 (best of 5) ! wall 1.382039 comb 1.380000 user 1.370000 sys 0.010000 (best of 8) # perfchangegroupchangelog on pypy ! wall 5.792589 comb 5.780000 user 5.780000 sys 0.000000 (best of 3) ! wall 3.911158 comb 3.920000 user 3.900000 sys 0.020000 (best of 3) # perfchangegroupchangelog on mozilla central ! wall 20.683727 comb 20.680000 user 20.630000 sys 0.050000 (best of 3) ! wall 14.190204 comb 14.190000 user 14.150000 sys 0.040000 (best of 3) Many tests have to be updated because of the change in bundle content. All theses update have been verified. Because diffing changelog was not very valuable, the resulting bundle have similar size (often a bit smaller): # full bundle of mozilla central with delta: 1142740533B without delta: 1142173300B So this is a win all over the board.
Fri, 14 Oct 2016 02:25:08 +0200 revlog: make 'storedeltachains' a "public" attribute
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 14 Oct 2016 02:25:08 +0200] rev 30210
revlog: make 'storedeltachains' a "public" attribute The next changeset will make that attribute read by the changegroup packer. We make it "public" beforehand.
Mon, 17 Oct 2016 22:51:22 -0700 manifest: don't store None in fulltextcache
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Oct 2016 22:51:22 -0700] rev 30209
manifest: don't store None in fulltextcache When we read a value from fulltextcache, we expect it to be an array, so we should not store None in it. Found while working on narrowhg.
Tue, 18 Oct 2016 02:09:08 +0200 copies: improve assertions during copy recombination
Gábor Stefanik <gabor.stefanik@nng.com> [Tue, 18 Oct 2016 02:09:08 +0200] rev 30208
copies: improve assertions during copy recombination - Make sure there is nothing to recombine in non-graftlike scenarios - More pythonic assert syntax
Mon, 17 Oct 2016 16:12:12 -0700 treemanifest: fix bad argument order to treemanifestctx
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Oct 2016 16:12:12 -0700] rev 30207
treemanifest: fix bad argument order to treemanifestctx Found by running tests with _treeinmem (both of them) modified to be True.
Sun, 16 Oct 2016 11:10:21 -0700 wireproto: compress data from a generator
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 16 Oct 2016 11:10:21 -0700] rev 30206
wireproto: compress data from a generator Currently, the "getbundle" wire protocol command obtains a generator of data, converts it to a util.chunkbuffer, then converts it back to a generator via the protocol's groupchunks() implementation. For the SSH protocol, groupchunks() simply reads 4kb chunks then write()s the data to a file descriptor. For the HTTP protocol, groupchunks() reads 32kb chunks, feeds those into a zlib compressor, emits compressed data as it is available, and that is sent to the WSGI layer, where it is likely turned into HTTP chunked transfer chunks as is or further buffered and turned into a larger chunk. For both the SSH and HTTP protocols, there is inefficiency from using util.chunkbuffer. For SSH, emitting consistent 4kb chunks sounds nice. However, the file descriptor it is writing to is almost certainly buffered. That means that a Python .write() probably doesn't translate into exactly what is written to the I/O layer. For HTTP, we're going through an intermediate layer to zlib compress data. So all util.chunkbuffer is doing is ensuring that the chunks we feed into the zlib compressor are of uniform size. This means more CPU time in Python buffering and emitting chunks in util.chunkbuffer but fewer function calls to zlib. This patch introduces and implements a new wire protocol abstract method: compresschunks(). It is like groupchunks() except it operates on a generator instead of something with a .read(). The SSH implementation simply proxies chunks. The HTTP implementation uses zlib compression. To avoid duplicate code, the HTTP groupchunks() has been reimplemented in terms of compresschunks(). To prove this all works, the "getbundle" wire protocol command has been switched to compresschunks(). This removes the util.chunkbuffer from that command. Now, data essentially streams straight from the changegroup emitter to the wire, possibly through a zlib compressor. Generators all the way, baby. There were slim to no performance changes on the server as measured with the mozilla-central repository. This is likely because CPU time is dominated by reading revlogs, producing the changegroup, and zlib compressing the output stream. Still, this brings us a little closer to our ideal of using generators everywhere.
Mon, 17 Oct 2016 19:48:36 +0200 revset: optimize for destination() being "inefficient"
Mads Kiilerich <madski@unity3d.com> [Mon, 17 Oct 2016 19:48:36 +0200] rev 30205
revset: optimize for destination() being "inefficient" destination() will scan through the whole subset and read extras for each revision to get its source.
Tue, 11 Oct 2016 04:39:47 +0200 copies: make _checkcopies handle copy sequences spanning the TCA (issue4028)
Gábor Stefanik <gabor.stefanik@nng.com> [Tue, 11 Oct 2016 04:39:47 +0200] rev 30204
copies: make _checkcopies handle copy sequences spanning the TCA (issue4028) When working in a rotated DAG (for a graftlike merge), there can be files that are renamed both between the base and the topological CA, and between the TCA and the endpoint farther from the base. Such renames span the TCA (and thus need both passes of _checkcopies to be fully detected), but may not necessarily be divergent. Make _checkcopies return "incomplete copies" and "incomplete divergences" in this case, and let mergecopies recombine them once data from both passes of _checkcopies is available. With this patch, all known cases involving renames and grafts pass. (Developed together with Pierre-Yves David)
Tue, 11 Oct 2016 04:25:59 +0200 checkcopies: add logic to handle remotebase
Gábor Stefanik <gabor.stefanik@nng.com> [Tue, 11 Oct 2016 04:25:59 +0200] rev 30203
checkcopies: add logic to handle remotebase As the two _checkcopies passes' ranges are separated by tca, not base, only one of the two passes will actually encounter the base. Pass "remotebase" to the other pass to let it know not to expect passing over the base. This is required for handling a few unusual rename cases.
Tue, 04 Oct 2016 12:51:54 +0200 mergecopies: add logic to process incomplete data
Gábor Stefanik <gabor.stefanik@nng.com> [Tue, 04 Oct 2016 12:51:54 +0200] rev 30202
mergecopies: add logic to process incomplete data We first combine incomplete copies on the two sides of the topological CA into complete copies. Any leftover incomplete copies are then combined with the incomplete divergences to reconstruct divergences spanning over the topological CA. Finally we promote any divergences falsely flagged as incomplete to full divergences. Right now, there is nothing generating incomplete copy/divergence data, so this code does nothing. Changes to _checkcopies to populate these dicts are coming later in this series.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip