i18n-pt_BR: synchronized with 7b428b00a1d4

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.)

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.

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.

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).

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).

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.

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.

Added signature for changeset 438173c41587

Added tag 4.0-rc for changeset 438173c41587

merge default into stable for 4.0 code freeze

merge with i18n

i18n-pt_BR: synchronized with 149433e68974

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.

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.

revlog: make 'storedeltachains' a "public" attribute The next changeset will make that attribute read by the changegroup packer. We make it "public" beforehand.

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.

copies: improve assertions during copy recombination - Make sure there is nothing to recombine in non-graftlike scenarios - More pythonic assert syntax

treemanifest: fix bad argument order to treemanifestctx Found by running tests with _treeinmem (both of them) modified to be True.

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.

revset: optimize for destination() being "inefficient" destination() will scan through the whole subset and read extras for each revision to get its source.

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)

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.

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.

checkcopies: handle divergences contained entirely in tca::ctx During a graftlike merge, _checkcopies runs from ctx to tca, possibly passing over the merge base. If there is a rename both before and after the base, then we're actually dealing with divergent renames. If there is no rename on the other side of tca, then the divergence is contained entirely in the range of one _checkcopies invocation, and should be detected "in the loop" without having to rely on the other _checkcopies pass.

update: enable copy tracing for backwards and non-linear updates As a followup to the issue4028 series, this fixes a variant of the issue that can occur when updating with uncommited local changes. The duplicated .hgsub warning is coming from wc.dirty(). We would previously skip this call because it's only relevant when we're going to perform copy tracing, which we didn't do before. The change to the update summary line is because we now treat the rename as a proper rename (which counts as a change), rather than an add+delete pair (which counts as a change and a delete).

bashcompletion: allow skipping completion for 'hg status' On systems with large repositories and slow disks, the calls to 'hg status' make autocomplete annoyingly slow. This fix makes it possible to avoid the slowdown.

tests: add more test coverage of phase changes when pushing Prepare for test coverage of phase updates with future push --readonly option, both with and without actually pushing changesets.

mergecopies: invoke _computenonoverlap for both base and tca during merges The algorithm of _checkcopies can only walk backwards in the DAG, never forward. Because of this, the two _checkcopies patches need to run from their respective endpoints to the TCA to cover the entire subgraph where the merge is being performed. However, detection of files new in both endpoints, as well as directory rename detection, need to run with respect to the merge base, so we need lists of new files both from the TCA's and the merge base's viewpoint to correctly detect renames in a graft-like merge scenario. (Series reworked by Pierre-Yves David)

copies: make it possible to distinguish betwen _computenonoverlap invocations _computenonoverlap needs to be invoked twice during a graft, and debugging messages should be distinguishable between the two invocations

copies: make _checkcopies handle simple renames in a rotated DAG This introduces a distinction between "merge base" and "topological common ancestor". During a regular merge, these two are identical. Graft, however, performs a merge in a rotated DAG, where the merge base will not be a common ancestor at all in the original DAG. To correctly find copies in case of a graft, we need to take both the merge base and the topological CA into account, and track any renames between them in reverse. Fortunately we can detect this in advance, see comment in the code about "backwards". This patch only supports finding non-divergent renames contained entirely between the merge base and the topological CA. Further patches are coming to support more complex cases. (Pierre-Yves David was involved in the cleanup of this patch.)

copies: compute a suitable TCA if base turns out to be unsuitable This will be used later in an update to _checkcopies. (Pierre-Yves David was involved in the cleanup of this patch.)

copies: detect graft-like merges Right now, nothing changes as a result of this, but we want to handle grafts differently from ordinary merges later. (Series developed together with Pierre-Yves David)

tests: introduce tests for grafting through renames These cover all currently known cases of renames being grafted, or changes being grafted through renames. Right now, most of these cases are broken. Later patches in this series will make them behave correctly. The testcases heavily rely on each other, which would make it very difficult to separate them and add them one-by-one for each case fixed by a patch. Separating them should perhaps be a 4.1 task, if it doesn't slow down the tests too much. (Developed together with Pierre-Yves David)

largefiles: fix 'deleted' files sometimes persistently appearing with R status A code snippet that has been around since largefiles was introduced was wrong: Standins no longer found in lfdirstate has *not* been removed - they have probably just been deleted ... or not created. This wrong reporting did that 'up -C' didn't undo the change and didn't sync the two dirstates. Instead of reporting such files as removed, propagate the deletion to the standin file and report the file as deleted.

largefiles: more safe handling of interruptions while updating modifications Largefiles are fragile with the design where dirstate and lfdirstate must be kept in sync. To be less fragile, mark all clean largefiles as unsure ("normallookup") before updating standins. After standins have been updated and we know exactly which largefile standins actually was changed, mark the unchanged largefiles back to clean ("normal"). This will make the failure mode more safe. If interrupted, the next command will continue to perform extra hashing of all largefiles. That will do that all largefiles that are out of sync with their standin will be marked dirty and they will show up in status and can be cleaned with update --clean.

largefiles: test coverage of fatal interruption of update Test using existing changesets in a clean working directory, revealing problems with files that don't show up as modified or do show up as removed when they just not have been written yet.

checkcopies: add a sanity check against false-positive copies When grafting a copy backwards through a rename, a copy is wrongly detected, which causes the graft to be applied inappropriately, in a destructive way. Make sure that the old file name really exists in the common ancestor, and bail out if it doesn't. This fixes the aggravated case of bug 5343, although the basic issue (failure to duplicate the copy information) still occurs.

exchange: refactor APIs to obtain bundle data (API) Currently, exchange.getbundle() returns either a cg1unpacker or a util.chunkbuffer (in the case of bundle2). This is kinda OK, as both expose a .read() to consumers. However, localpeer.getbundle() has code inferring what the response type is based on arguments and converts the util.chunkbuffer returned in the bundle2 case to a bundle2.unbundle20 instance. This is a sign that the API for exchange.getbundle() is not ideal because it doesn't consistently return an "unbundler" instance. In addition, unbundlers mask the fact that there is an underlying generator of changegroup data. In both cg1 and bundle2, this generator is being fed into a util.chunkbuffer so it can be re-exposed as a file object. util.chunkbuffer is a nice abstraction. However, it should only be used "at the edges." This is because keeping data as a generator is more efficient than converting it to a chunkbuffer, especially if we convert that chunkbuffer back to a generator (as is the case in some code paths currently). This patch refactors exchange.getbundle() into exchange.getbundlechunks(). The new API returns an iterator of chunks instead of a file-like object. Callers of exchange.getbundle() have been updated to use the new API. There is a minor change of behavior in test-getbundle.t. This is because `hg debuggetbundle` isn't defining bundlecaps. As a result, a cg1 data stream and unpacker is being produced. This is getting fed into a new bundle20 instance via bundle2.writebundle(), which uses a backchannel mechanism between changegroup generation to add the "nbchanges" part parameter. I never liked this backchannel mechanism and I plan to remove it someday. `hg bundle` still produces the "nbchanges" part parameter, so there should be no user-visible change of behavior. I consider this "regression" a bug in `hg debuggetbundle`. And that bug is captured by an existing "TODO" in the code to use bundle2 capabilities.

mergecopies: rename 'ca' to 'base' This variable was named after the common ancestor. It is actually the merge base that might differ from the common ancestor in the graft case. We rename the variable before a larger refactoring to clarify the situation. Similar rename was also applied to 'checkcopies' in a prior changeset.

copies: move variable document from checkcopies to mergecopies It appears that 'mergecopies' is the function consuming these data so we move the documentation there.

checkcopies: pass data as a dictionary of dictionaries more are coming

checkcopies: move 'movewithdir' initialisation right before its usage The 'movewithdir' had a lot of related logic all around the 'mergecopies'. However it is actually never containing anything until the very last loop in that function. We move the (simplified) variable definition there for clarity

cmdutil: satisfy expections in dirstateguard.__del__, even if __init__ fails Python "delstructors" are terrible - this one because it assumed that __init__ had completed before it was called. That would not necessarily be the case if the repository was read only or broken and saving the dirstate thus failed in unexpected ways. That could give confusing warnings about missing '_active' after failures. To fix that, make sure all member variables are "declared" before doing anything that possibly could fail. [Famous last words.]

util: increase filechunkiter size to 128k util.filechunkiter has been using a chunk size of 64k for more than 10 years, also in years where Moore's law still was a law. It is probably ok to bump it now and perhaps get a slight win in some cases. Also, largefiles have been using 128k for a long time. Specifying that size multiple times (or forgetting to do it) seems a bit stupid. Decreasing it to 64k also seems unfortunate. Thus, we will set the default chunksize to 128k and use the default everywhere.

largefiles: always use filechunkiter when iterating files Before, we would sometimes use the default iterator over large files. That iterator is line based and would add extra buffering and use odd chunk sizes which could give some overhead. copyandhash can't just apply a filechunkiter as it sometimes is passed a genuine generator when downloading remotely.

revset: for x^2, do not take null as a valid p2 revision Since we don't count null p2 revision as a parent, x^2 should never return null even if null is explicitly populated.

revset: make follow() reject more than one start revisions Taking only the last revision is inconsistent because ancestors(set) follows all revisions given, and theoretically follow(startrev=set) == ancestors(set). I'm planning to add a support for multiple start revisions, but that won't fit to the 4.0 time frame. So reject multiple revisions now to avoid future BC. len(revs) might be slow if revs were large, but we don't care since a valid revs should have only one element.

bundle2: only emit compressed chunks if they have data This is similar to 58467204cac0. Not all calls into the compressor return compressed data, as the compressor may buffer compressed output internally. It is cheaper to check for empty chunks than to send empty chunks through the generator. When generating a gzip-v2 bundle of the mozilla-unified repo, this change results in 50,093 empty chunks not being sent through the generator (out of 1,902,996 total input chunks).

color: add some documentation for custom terminfo codes

color: debugcolor should emit the user-defined colors This also fixes a long-standing bug that reversed the sense of the color name and the label used to print it, which was never relevant before.

color: ignore effects missing from terminfo If terminfo mode is in effect, and an effect is used which is missing from the terminfo database, simply silently ignore the request, leaving the output unaffected rather than causing a crash.

color: allow for user-configurable terminfo codes for effects If the entry in the terminfo database for your terminal is missing some attributes, it should be possible to create them on the fly without resorting to just making them a color. This change allows you to have [color] terminfo.<effect> = <code> where <effect> might be something like "dim" or "bold", and <code> is the escape sequence that would otherwise have come from a call to tigetstr(). If an escape character is needed, use "\E". Any such settings will override attributes that are present in the terminfo database.

update: warn if cwd was deleted During update directories are deleted as soon as they have no entries. But if current working directory is deleted then it cause problems in complex commands like 'hg split'. This commit adds a warning that will help users figure the problem faster.

parsers: avoid PySliceObject cast on Python 3 PySlice_GetIndicesEx() accepts a PySliceObject* on Python 2 and a PyObject* on Python 3. Casting to PySliceObject* on Python 3 was yielding a compiler warning. So stop doing that. With this patch, I no longer see any compiler warnings when building the core extensions for Python 3!

bdiff: include util.h Without this, IS_PY3K isn't define and the preprocessor uses the incorrect module loading code, causing the module fail to load at run-time. After this patch, all our C extensions (except for watchman's) appear to import correctly in Python 3!

parsers: alias more PyInt* symbols on Python 3 I feel dirty for having to do this. But this is currently our approach for dealing with PyInt -> PyLong in Python 3 for this file. This removes a ton of compiler warnings by fixing unresolved symbols.

manifest: use PyVarObject_HEAD_INIT More appeasing the Python 3 and compiler overlords. The code is equivalent.

dirs: use PyVarObject_HEAD_INIT This makes a compiler warning go away on Python 3.

py3: use namedtuple._replace to produce new tokens

py3: refactor token parsing to handle call args properly The token parsing was getting unwieldy and was too naive about accessing arguments.

eol: make sure we always release the wlock when writing cache If any exception were to happen after we acquired the wlock, we could leave it unreleased. We move the wlock release in a 'finally:' close as it should be.

pathencode: use assert() for PyBytes_Check() This should have been added in a8c948ee3668. I sent the patch to the list prematurely.

merge: clarify warning for (not) merging flags without ancestor Give hints why it can't merge and what it will do instead.

merge: only show "cannot merge flags for %s" warning if flags are different

tests: add test coverage of merging x flag without ancestor It is more noisy than necessary - we will fix that later.

dirs: document Py_SIZE weirdness Assigning to what looks like a function is clown shoes. Document that it is a macro referring to a struct member.

record: return code from underlying commit

commit: return 1 for interactive commit with no changes (issue5397) For consistency with non interactive commit

demandimport: disable lazy import of __builtin__ Demandimport uses the "try to import __builtin__, else use builtins" trick to handle Python 3. External libraries and extensions might do something similar. On Fedora 25 subversion-python-1.9.4-4.fc25.x86_64 will do just that (except the opposite) ... and it failed all subversion convert tests because demandimport was hiding that it didn't have builtins but should use __builtin__. The builtin module has already been imported when demandimport is loaded so there is no point in trying to import it on demand. Just always ignore both variants in demandimport.

changelog: disable delta chains This patch disables delta chains on changelogs. After this patch, new entries on changelogs - including existing changelogs - will be stored as the fulltext of that data (likely compressed). No delta computation will be performed. An overview of delta chains and data justifying this change follows. Revlogs try to store entries as a delta against a previous entry (either a parent revision in the case of generaldelta or the previous physical revision when not using generaldelta). Most of the time this is the correct thing to do: it frequently results in less CPU usage and smaller storage. Delta chains are most effective when the base revision being deltad against is similar to the current data. This tends to occur naturally for manifests and file data, since only small parts of each tend to change with each revision. Changelogs, however, are a different story. Changelog entries represent changesets/commits. And unless commits in a repository are homogonous (same author, changing same files, similar commit messages, etc), a delta from one entry to the next tends to be relatively large compared to the size of the entry. This means that delta chains tend to be short. How short? Here is the full vs delta revision breakdown on some real world repos: Repo % Full % Delta Max Length hg 45.8 54.2 6 mozilla-central 42.4 57.6 8 mozilla-unified 42.5 57.5 17 pypy 46.1 53.9 6 python-zstandard 46.1 53.9 3 (I threw in python-zstandard as an example of a repo that is homogonous. It contains a small Python project with changes all from the same author.) Contrast this with the manifest revlog for these repos, where 99+% of revisions are deltas and delta chains run into the thousands. So delta chains aren't as useful on changelogs. But even a short delta chain may provide benefits. Let's measure that. Delta chains may require less CPU to read revisions if the CPU time spent reading smaller deltas is less than the CPU time used to decompress larger individual entries. We can measure this via `hg perfrevlog -c -d 1` to iterate a revlog to resolve each revision's fulltext. Here are the results of that command on a repo using delta chains in its changelog and on a repo without delta chains: hg (forward) ! wall 0.407008 comb 0.410000 user 0.410000 sys 0.000000 (best of 25) ! wall 0.390061 comb 0.390000 user 0.390000 sys 0.000000 (best of 26) hg (reverse) ! wall 0.515221 comb 0.520000 user 0.520000 sys 0.000000 (best of 19) ! wall 0.400018 comb 0.400000 user 0.390000 sys 0.010000 (best of 25) mozilla-central (forward) ! wall 4.508296 comb 4.490000 user 4.490000 sys 0.000000 (best of 3) ! wall 4.370222 comb 4.370000 user 4.350000 sys 0.020000 (best of 3) mozilla-central (reverse) ! wall 5.758995 comb 5.760000 user 5.720000 sys 0.040000 (best of 3) ! wall 4.346503 comb 4.340000 user 4.320000 sys 0.020000 (best of 3) mozilla-unified (forward) ! wall 4.957088 comb 4.950000 user 4.940000 sys 0.010000 (best of 3) ! wall 4.660528 comb 4.650000 user 4.630000 sys 0.020000 (best of 3) mozilla-unified (reverse) ! wall 6.119827 comb 6.110000 user 6.090000 sys 0.020000 (best of 3) ! wall 4.675136 comb 4.670000 user 4.670000 sys 0.000000 (best of 3) pypy (forward) ! wall 1.231122 comb 1.240000 user 1.230000 sys 0.010000 (best of 8) ! wall 1.164896 comb 1.160000 user 1.160000 sys 0.000000 (best of 9) pypy (reverse) ! wall 1.467049 comb 1.460000 user 1.460000 sys 0.000000 (best of 7) ! wall 1.160200 comb 1.170000 user 1.160000 sys 0.010000 (best of 9) The data clearly shows that it takes less wall and CPU time to resolve revisions when there are no delta chains in the changelogs, regardless of the direction of traversal. Furthermore, not using a delta chain means that fulltext resolution in reverse is as fast as iterating forward. So not using delta chains on the changelog is a clear CPU win for reading operations. An example of a user-visible operation showing this speed-up is revset evaluation. Here are results for `hg perfrevset 'author(gps) or author(mpm)'`: hg ! wall 1.655506 comb 1.660000 user 1.650000 sys 0.010000 (best of 6) ! wall 1.612723 comb 1.610000 user 1.600000 sys 0.010000 (best of 7) mozilla-central ! wall 17.629826 comb 17.640000 user 17.600000 sys 0.040000 (best of 3) ! wall 17.311033 comb 17.300000 user 17.260000 sys 0.040000 (best of 3) What about 00changelog.i size? Repo Delta Chains No Delta Chains hg 7,033,250 6,976,771 mozilla-central 82,978,748 81,574,623 mozilla-unified 88,112,349 86,702,162 pypy 20,740,699 20,659,741 The data shows that removing delta chains from the changelog makes the changelog smaller. Delta chains are also used during changegroup generation. This operation essentially converts a series of revisions to one large delta chain. And changegroup generation is smart: if the delta in the revlog matches what the changegroup is emitting, it will reuse the delta instead of recalculating it. We can measure the impact removing changelog delta chains has on changegroup generation via `hg perfchangegroupchangelog`: hg ! wall 1.589245 comb 1.590000 user 1.590000 sys 0.000000 (best of 7) ! wall 1.788060 comb 1.790000 user 1.790000 sys 0.000000 (best of 6) mozilla-central ! wall 17.382585 comb 17.380000 user 17.340000 sys 0.040000 (best of 3) ! wall 20.161357 comb 20.160000 user 20.120000 sys 0.040000 (best of 3) mozilla-unified ! wall 18.722839 comb 18.720000 user 18.680000 sys 0.040000 (best of 3) ! wall 21.168075 comb 21.170000 user 21.130000 sys 0.040000 (best of 3) pypy ! wall 4.828317 comb 4.830000 user 4.820000 sys 0.010000 (best of 3) ! wall 5.415455 comb 5.420000 user 5.410000 sys 0.010000 (best of 3) The data shows eliminating delta chains makes the changelog part of changegroup generation slower. This is expected since we now have to compute deltas for revisions where we could recycle the delta before. It is worth putting this regression into context of overall changegroup times. Here is the rough total CPU time spent in changegroup generation for various repos while using delta chains on the changelog: Repo CPU Time (s) CPU Time w/ compression hg 4.50 7.05 mozilla-central 111.1 222.0 pypy 28.68 75.5 Before compression, removing delta chains from the changegroup adds ~4.4% overhead to hg changegroup generation, 1.3% to mozilla-central, and 2.0% to pypy. When you factor in zlib compression, these percentages are roughly divided by 2. While the increased CPU usage for changegroup generation is unfortunate, I think it is acceptable because the percentage is small, server operators (those likely impacted most by this) have other mechanisms to mitigate CPU consumption (namely reducing zlib compression level and pre-generated clone bundles), and because there is room to optimize this in the future. For example, we could use the nullid as the base revision, effectively encoding the full revision for each entry in the changegroup. When doing this, `hg perfchangegroupchangelog` nearly halves: mozilla-unified ! wall 21.168075 comb 21.170000 user 21.130000 sys 0.040000 (best of 3) ! wall 11.196461 comb 11.200000 user 11.190000 sys 0.010000 (best of 3) This looks very promising as a future optimization opportunity. It's worth that the changes in test-acl.t to the changegroup part size. This is because revision 6 in the changegroup had a delta chain of length 2 before and after this patch the base revision is nullrev. When the base revision is nullrev, cg2packer.deltaparent() hardcodes the *previous* revision from the changegroup as the delta parent. This caused the delta in the changegroup to switch base revisions, the delta to change, and the size to change accordingly. While the size increased in this case, I think sizes will remain the same on average, as the delta base for changelog revisions doesn't matter too much (as this patch shows). So, I don't consider this a regression.

revlog: add instance variable controlling delta chain use This is to support disabling delta chains on the changelog in a subsequent patch.

changegroup: document deltaparent's choice of previous revision As part of debugging low-level changegroup generation, I came across what I initially thought was a weird behavior: changegroup v2 is choosing the previous revision in the changegroup as a delta base instead of p1. I was tempted to rewrite this to use p1, as p1 will delta better than prev in the common case. However, I realized that taking p1 as the base would potentially require resolving a revision fulltext and thus require more CPU for e.g. server-side processing of getbundle requests. This patch tweaks the code comment to note the choice of behavior. It also notes there is room for a flag or config option to tweak this behavior later: using p1 as the delta base would likely make changegroups smaller at the expense of more CPU, which could be beneficial for things like clone bundles.

help: backout f3c4edfd35e1 (mark boolean flags with [no-] in help) for now The ability to negate any boolean flags itself is great, but I think we are not ready to expose the help side of it yet. First, while there exist a handful of such flags whose default value can be changed (eg: git diff, patchwork confirmation), there is only a few of them. The users who benefit the most from this change are alias users and large installation that can deploy extension to change behavior (eg: facebook tweakdefault). So the majority of user who will be affected by a large change to command help that is not yet relevant to them. (I expect this to become relevant when ui.progressive start to exists). Below is an example of the impact of the new help on 'hg help diff': -r --rev REV [+] revision -c --change REV change made by revision -a --[no-]text treat all files as text -g --[no-]git use git extended diff format --[no-]nodates omit dates from diff headers --[no-]noprefix omit a/ and b/ prefixes from filenames -p --[no-]show-function show which function each change is in --[no-]reverse produce a diff that undoes the changes -w --[no-]ignore-all-space ignore white space when comparing lines -b --[no-]ignore-space-change ignore changes in the amount of white space -B --[no-]ignore-blank-lines ignore changes whose lines are all blank -U --unified NUM number of lines of context to show --[no-]stat output diffstat-style summary of changes --root DIR produce diffs relative to subdirectory -I --include PATTERN [+] include names matching the given patterns -X --exclude PATTERN [+] exclude names matching the given patterns -S --[no-]subrepos recurse into subrepositories Another issue with the current state of help, the default value for the flag is not conveyed to the user. For example in the 'backout' help, there is no real distinction between "--[no-]backup" (default to True) and "--[no-]keep" (default) to False: --[no-]backup no backups --[no-]keep do not modify working directory during strip In addition, I've discussed with Augie Fackler and the last batch of the work on this have burned him out quite some. Therefore he is not intending to perform any more work on this topic. Quoting him, he would rather see the help part backed out than spending more time on it. I do not think we are ready to expose this to users in 4.0 (freeze in a week), especially because we cannot expect quick improvement on these aspect as this topic no longer have an owner. We should be able to reintroduce that change in the future when someone get back on it and the main issues are solves: * Introduction of ui.progressive makes it relevant for a majority of user, * Current default value are efficiently conveyed to the user. (In addition, the excerpt from diff help show that we still have some issue with some negative option like '--nodates' so further improvement are probably welcome there.)

copy: distinguish "file exists" cases and add a hint (BC) Users that want to add a copy record to an existing commit with 'hg commit --amend' should be guided towards this workflow, rather than reaching for some sort of uncommit-recommit flow. As part of this, distinguish in the top-line error message whether the file merely already exists (untracked) on disk or the file already exists in history. The full list of copy and rename cases and how they interact with flags are listed below: target exists --after --force | action n n * | copy n y * | (1) untracked n n | (4) NEWHINT untracked n y | (3) untracked y * | (2) y n n | (4) NEWHINT y n y | (3) y y n | (2) y y y | (3) deleted n n | copy deleted n y | (3) deleted y n | (1) deleted y y | (1) * = don't care (1) <src>: not recording move - <target> does not exist (2) preserve target contents (3) replace target contents (4) <target>: not overwriting - file {exists,already committed} Credit to Kevin for wholly rewriting my table to cover more cases we discovered at the sprint. I think this change gets the hints correct in all cases, but I'd appreciate close inspection of the test cases to make sure I haven't gotten turned around in here.

perf: make perftags clear tags cache correctly Before this patch, "hg perftags" command doesn't measure performance of "repo.tags()" correctly, because it doesn't clear tags cache correctly. 9dca7653b525 replaced repo._tags with repo._tagscache, but didn't change the code path to clear tags cache in perftags() at that time. BTW, full history of "tags cache" is: - d7df759d0e97 (or 0.6) introduced repo.tagscache as the first "tags cache" - 5614a628d173 (or 1.4) replaced repo.tagscache with repo._tags - 9dca7653b525 (or 2.0) replaced repo._tags with repo._tagscache - 98c867ac1330 (or 2.5) made repo._tagscache filteredpropertycache To make perftags clear tags cache correctly, and to increase "historical portability" of perftags, this patch examines existence of attributes in repo object, and guess appropriate procedure to clear tags cache. To avoid examining existence of attributes at each repetition, this patch makes repocleartagscachefunc() return the function, which actually clears tags cache. mozilla-central repo (85 tags on 308365 revs) with each Mercurial version between before and after this patch. ==== ========= ========= ver before after ==== ========= ========= 1.9 0.476062 0.466464 ------- *1 ------- 2.0 0.346309 0.458327 2.1 0.343106 0.454489 ------- *2 ------- 2.2 0.069790 0.071263 2.3 0.067829 0.069340 2.4 0.068075 0.069573 ------- *3 ------- 2.5 0.021896 0.022406 2.6 0.021900 0.022374 2.7 0.021883 0.022379 2.8 0.021949 0.022327 2.9 0.021877 0.022330 3.0 0.021860 0.022314 3.1 0.021869 0.022669 3.2 0.021831 0.022668 3.3 0.021809 0.022691 3.4 0.021861 0.022916 3.5 0.019335 0.020749 3.6 0.019319 0.020866 3.7 0.018781 0.020251 ------- *4 ------- 3.8 0.068262 0.072558 3.9 0.069682 0.073773 ==== ========= ========= (*1) repo._tags was replaced with repo._tagscache at this point "repo._tags = None" in perftags "before" this patch doesn't clear tags cache for Mercurial 2.0 or later. This causes significant gap of "before" between 1.9 and 2.0 . (*2) I'm not sure about significant gap at this point, but release note of 2.2 described "a number of significant performance improvements for large repositories" (*3) filtered changelog was cached in repoview as repoview.changelog at this point (by 4d92e2d75cff) This avoids calculation of filtered changelog at each repetition of t(). (*4) calculation of filtered changelog was included into wall time at this point (by 332926212ef8), again See below for detail about this significant gap: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-April/083410.html

perf: replace ui.configint() by getint() for Mercurial earlier than 1.9 Before this patch, using ui.configint() prevents perf.py from measuring performance with Mercurial earlier than 1.9 (or fa2b596db182), because ui.configint() isn't available in such Mercurial, even though there are some code paths for Mercurial earlier than 1.9 in perf.py. For example, setting "_prereadsize" attribute in perfindex() and perfnodelookup() is effective only with hg earlier than 1.8 (or 61c9bc3da402). This patch replaces ui.configint() invocations by newly introduced getint(). This patch also adds check-perf-code.py an extra check entry to detect direct usage of ui.configint() in perf.py. BTW, this patch doesn't choose adding configint() method at runtime by replacing ui.__class__ like below, even though this is the recommended way to modern Mercurial extensions. def uisetup(ui): if not util.safehasattr(ui, 'configint'): class uiwrap(ui.__class__): def configint(self, section, name, ....): .... ui.__class__ = uiwrap Because changes to ui.__class__ by uisetup() of loaded extension have been propagated since 1.6.1 (or d8d0fc3988ca), the recommended way above doesn't work as expected with Mercurial earlier than it.

perf: omit copying from ui.ferr to ui.fout for Mercurial earlier than 1.9 Before this patch, referring ui.ferr prevents perf.py from measuring performance with Mercurial earlier than 1.9 (or 4e1ccd4c2b6d), because ui.ferr isn't available in such Mercurial, even though there are some code paths for Mercurial earlier than 1.9 in perf.py. For example, setting "_prereadsize" attribute in perfindex() and perfnodelookup() is effective only with hg earlier than 1.8 (or 61c9bc3da402).

perf: define formatter locally for Mercurial earlier than 2.2 Before this patch, using ui.formatter() prevents perf.py from measuring performance with Mercurial earlier than 2.2 (or ae5f92e154d3), because ui.formatter() isn't available in such Mercurial, even though there are some code paths for Mercurial earlier than 2.2 in perf.py. For example, setting "_prereadsize" attribute in perfindex() and perfnodelookup() is effective only with hg earlier than 1.8 (or 61c9bc3da402). This patch defines formatter class locally, and use it instead of the value returned by ui.formatter(), if perf.py is used with Mercurial earlier than 2.2. In this case, we don't need to think about -T/--template option for formatter, because previous patch made -T/--template disabled for perf.py with Mercurial earlier than 3.2 (or 7a7eed5176a4).

perf: add functions to get vfs-like object for Mercurial earlier than 2.3 Before this patch, using svfs prevents perf.py from measuring performance of Mercurial earlier than 2.3 (or 7034365089bf), because svfs isn't available in such Mercurial, even though there are some code paths for Mercurial earlier than 2.3 in perf.py. For example, setting "_prereadsize" attribute in perfindex() and perfnodelookup() is effective only with hg earlier than 1.8 (or 61c9bc3da402). To get appropriate vfs-like object to access files under .hg/store, this patch adds getsvfs() (and also getvfs(), for future use). To avoid examining existence of attribute at each repetition while measuring performance, getsvfs() is invoked outside the function to be called repeatedly. This patch also adds check-perf-code.py an extra check entry to detect direct usage of repo.(vfs|svfs|opener|sopener) in perf.py.

perf: avoid actual writing branch cache out correctly Mercurial 2.5 (or 9b6ae29d4801) introduced "perfbranchmap" command, and tried to avoid actual writing branch cache out by replacing write() of branchcache class in branchmap.py with no-op function (probably, for elimination of noisy and heavy file I/O factor). But its implementation isn't correct, because 9b6ae29d4801 replaced not branchmap.branchcache.write() but branchmap.write(). The latter doesn't exist, even at that change. To avoid actual writing branch cache out correctly, this patch replaces branchmap.branchcache.write() with no-op function. To detect mistake of replacement or change of API in the future quickly, this patch uses safeattrsetter() instead of direct attribute assignment. For similarity between replacements, this patch also changes replacement of branchmap.read(). In this patch, replacement of read()/write() can run safely outside "try" block, because two safeattrsetter() invocations ensure that replacement doesn't cause exception. FYI, the table below compares "base" filter wall time of perfbranchmap on recent mozilla-central repo with each Mercurial version between before and after this patch. ==== ========= ========= ver before after ==== ========= ========= 2.5 18.492334 18.232455 2.6 18.733858 18.156702 2.7 18.245598 18.349210 2.8 18.289070 18.528422 2.9 17.572742 16.989655 3.0 17.406953 17.615012 3.1 17.228419 17.689805 3.2 17.862961 17.718367 3.3 2.632110 2.707960 3.4 3.285683 3.272060 3.5 3.370141 3.352176 3.6 3.366939 3.242455 3.7 3.300778 3.367328 3.8 3.300132 3.267298 3.9 3.418996 3.370265 ==== ========= ========= IMHO, there is no serious overlooking performance regression.

perf: get subsettable from appropriate module for Mercurial earlier than 2.9 Before this patch, using branchmap.subsettable prevents perfbranchmap from measuring performance of Mercurial earlier than 2.9 (or 175c6fd8cacc), because 175c6fd8cacc moved subsettable from repoview.py to branchmap.py, even though there are some code paths for Mercurial earlier than 2.9 in perf.py. For example, setting "_prereadsize" attribute in perfindex() and perfnodelookup() is effective only with hg earlier than 1.8 (or 61c9bc3da402). To get subsettable from appropriate module, this patch examines existence of subsettable in branchmap and repoview. This patch also adds check-perf-code.py an extra check entry to detect direct usage of subsettable attribute in perf.py.

perf: introduce safeattrsetter to replace direct attribute assignment Referring not-existing attribute immediately causes failure, but assigning a value to such attribute doesn't. For example, perf.py has code paths below, which assign a value to not-existing attribute. This causes incorrect performance measurement, but these code paths are executed successfully. - "repo._tags = None" in perftags() recent Mercurial has tags cache information in repo._tagscache - "branchmap.write = lambda repo: None" in perfbranchmap() branchmap cache is written out by branchcache.write() in branchmap.py "util.safehasattr() before assignment" can avoid this issue, but might increase mistake at "copy & paste" attribute name or so. To centralize (1) examining existence of, (2) assigning a value to, and (3) restoring an old value to the attribute, this patch introduces safeattrsetter(). This is used to replace direct attribute assignment in subsequent patches. Encapsulation of restoring is needed to completely remove direct attribute assignment from perf.py, even though restoring isn't needed so often.

largefiles: use context for file closing Make the code slightly smaller and safer (and more deeply indented).

largefiles: when setting/clearing x bit on largefiles, don't change other bits It is only the X bit that it matters to copy from the standin to the largefile in the working directory. While it generally doesn't do any harm to copy the whole mode, it is also "wrong" to copy more than the X bit we care about. It can make a difference if someone should try to handle largefiles differently, such as marking them read-only. Thus, do similar to what utils.setflags does and set the X bit where there are R bits and obey umask.

eol: on update, only re-check files if filtering changed Before, update would mark all files as 'normallookup' in dirstate if .hgeol changed so all files would get the new filtering applied. That takes some time ... and is pointless if the filtering for that file didn't change. Instead, keep track of the old filtering and only check files where the filtering is changed. To keep the old filtering, change to write the applied .hgeol content to .hg/eol.cache instead of just touching it. That change is backwards/forwards compatible. In a real world test, this takes an update that is changing .hgeol and 30000 files from 12s to 4s - where the remaining eol overhead is 1-2s.

dirs: add comment about _PyBytes_Resize So readers have a canonical function to compare this code to.

checkcopies: extract the '_related' closure There is not need for it to be a closure.

checkcopies: add an inline comment about the '_related' call This helps understanding the flow of the function.

checkcopies: minor change to comment This helped me understand the refactoring so this must be helpful.

checkcopies: rename 'ca' to 'base' This variable was named after the common ancestor. It is actually the merge base that might differ from the common ancestor in the graft case. We rename the variable before a larger refactoring to clarify the situation.

bisect: extra a small initialisation outside of a loop Having initialisation done during the first iteration is cute, but can be avoided.

pycompat: only accept a bytestring filepath in Python 2

py3: use raw strings in line continuation (convert ext) Our py2 to py3 string translations marks those as bytestrings.

py3: namedtuple takes unicode (journal ext) namedtuple usage consistent with changelog.py:141

debuginstall: use %d instead of %s for formatting an int % formatting on bytes on Python 3 is pickier about which % character we specify.

py3: test to check which commands run This test helps us to keep track on the commands which runs to Python 3. The full traceback is hidden. Thanks to Augie and Martijn to wrap it up in four lines.

bisect: build a displayer only once There is multiple spot using this, building it early will help to extract more of the logic into the bisect module.

bisect: factor commonly update sequence For now, This remains a closure in the module to avoid circular import with used module.

bisect: move check_state into the bisect module Now that the function is simpler, we resume our quest to move the logic into the bisect module. In the process, we add basic documentation.

bisect: simplify conditional in 'check_state' Now that extra code about "updating" flag have been removed, we can simplify the condition flow and remove a level.

bisect: remove code about "update-flag" in check_state Now that the flag dedicated to updating the flag are handled earlier, we do not need to handle them in the 'check_state' function.

bisect: rename 'check_code' to match our naming scheme We need to do it early, otherwise 'check-commit' will complain every time we touch it.

bisect: minor movement of code handle flag updating state The code flag handling is quite complicated, we are moving code around to prepare further simplification.

test-clone: discard lock-related messages We can't predict where those will show up and they're not super-important for the contents of this particular test, so just drop them. Further reduces the flakiness of the test to zero.

test-clone: fix some instability in pooled clone race condition test Healthy output (one log file mentioning "existing pooled" and one mentioning "new pooled") will now print in a stable order, but unhealthy output will print some sort of error. This reduces the flakiness of the test from 55% to 38%. My next patch makes it completely stable.

py3: add an os.fsencode backport to ease path handling

py3: a second argument to open can't be bytes This fixes open(filename, 'r'), open(filename, 'w'), etc. calls. In Python 3, that second argument *must* be a string, you can't use bytes. The fix is the same as used with getattr() (where the second argument must also always be a string); in the tokenizer, where we detect calls, if there is something that looks like a call to open (and is not an attribute, so the previous token is not a "." dot) then make sure that that second argument is not converted to a `bytes` object instead. There is some remaining issue where the current transformer will also rewrite open(f('foo')). However this also affect function for which we perform similar rewrite ('getattr', 'setattr', 'hasattr', 'safehasattr') and will be dealt with in a follow up.

py3: make check-py3-compat.py import importlib only if necessary importlib isn't available on Python 2.6, and it isn't necessary for Py2 checks.

templater: handle division by zero in arithmetic For now, just turn it to an abort.

templater: provide arithmetic operations on integers The termwidth template keyword is of limited use without some way to ensure that margins are respected. Provide a full set of arithmetic operators (four basic operations plus the mod function, defined to match Python's // for division), so that you can create termwidth based layouts that match the user's terminal size

eol: store and reuse pattern matchers instead of creating in tight loop More "right" and more efficient.

eol: fix variable naming - call it _eolmatch instead of _eolfile It is not the file but a match object based on it.

parsers: move PyInt aliasing out of util.h The PyInt aliasing is only used by parsers.c. Since we don't want to encourage the use of PyInt parsing, move the aliasing to parsers.c.

osutil: use PyLongObject on Python 3 for listdir_slot This code looks performance sensitive. So let's retain PyIntObject on Python 2 and use PyLongObject explicitly on Python 3.

osutil: use PyLongObject in recvfds PyIntObject doesn't exist in Python 3. While PyIntObject is preferred on Python 2 because it is a fixed capacity and faster, the difference between PyIntObject and PyLongObject for scenarios where performance isn't critical or the caller isn't performing type checking shouldn't be relevant. So change recvfds to return a list of longs instead of ints on Python 2.

py3: use encoding.environ instead of os.environ This complains while running hg version on Python 3.5

store: py26 compat, don't use a dict comprehension

dirs: document performance reasons for bypassing Python C API So someone isn't tempted to change it.

dirs: port PyInt code to work on Python 3 PyIntObject no longer exists in Python 3. Instead, there is PyLongObject. Furthermore, PyInt_AS_LONG is a macro referencing a struct member. PyInt_AS_LONG doesn't exist in Python 3 and PyLong_AS_LONG is a #define for PyLong_AsLong, which is a function. So assigning to the return value of PyLong_AS_LONG doesn't work. This patch introduces a macro for obtaining the value of an integer-like type that works on Python 2 and Python 3. On Python 3, we access the struct field of the underlying PyLongObjet directly, without overflow checking. This is essentially the same as what Python 2 was doing except using a PyLong instead of a PyInt.