localrepo: factor out base of filecache annotation class It isn't needed that storecache is derived from repofilecache. Changes in this patch allow repofilecache and storecache to do in own __init__() differently from each other.

manifest: apply checkambig=True only for root 00manifest.i This is a fix for my 14ad8e2a4abe, which used 'bool(dir)' as checkambig value for revlog.__init__(). I can't remember why I did so in 14ad8e2a4abe, but this is obviously wrong, because only root indexfile is cached via filecache-ed property of localrepository.

revlog: address review feedback for deltachain C implementation * Scope of "value" is reduced * index_baserev() is documented * Error is no longer redundantly set for -2 return values * Error values are compared <= -2 instead of == -2 to protect against odd failure scenarios

test-rebase-interruptions: stabilize for Windows External hooks end up launching cmd.exe, which knows nothing about $VAR syntax. For some reason, I thought that Mercurial would substitute in the value, in order to paper over the platform difference. But I can't find that in the documentation, and there's at least one other use of this pattern [1]. [1] https://www.mercurial-scm.org/repo/hg/file/tip/tests/test-histedit-fold.t#l477

drawdag: inline transaction() function I suspect Jun wrote the method before he learnt that Python 2.7 allows multiple context managers in a single with-clause.

revlog: C implementation of delta chain resolution I've seen revlog._deltachain() appear in a number of performance profiles. I suspect there are 2 reasons for this: 1. Delta chain resolution performs many index lookups, thus triggering population of index tuples. Creating possibly tens of thousands of PyObject will have overhead. 2. Delta chain resolution is a tight loop. By moving delta chain resolution to C, we can defer instantiation of full index entry tuples and make the loop faster courtesy of not running in Python. We can measure the impact to delta chain resolution via `hg perflogrevision` using the mozilla-central repo with a recent manifest having delta chain length of 33726: $ hg perfrevlogrevision -m 364895 ! full ! wall 0.367585 comb 0.370000 user 0.340000 sys 0.030000 (best of 27) ! wall 0.357581 comb 0.360000 user 0.350000 sys 0.010000 (best of 28) ! deltachain ! wall 0.010644 comb 0.010000 user 0.010000 sys 0.000000 (best of 270) ! wall 0.000292 comb 0.000000 user 0.000000 sys 0.000000 (best of 8729) $ hg perfrevlogrevision --cache -m 364895 ! deltachain ! wall 0.003904 comb 0.000000 user 0.000000 sys 0.000000 (best of 712) ! wall 0.000284 comb 0.000000 user 0.000000 sys 0.000000 (best of 9926) The first test measures savings from both not instantiating index entries and moving to C. The second test (which doesn't clear the index caches) essentially isolates the benefits of moving from Python to C. It still shows a 13.7x speedup (versus 36.4x). And there are multiple milliseconds of savings within the critical path for resolving revision data. I think that justifies the existence of C code. A more striking example of the benefits of this change can be demonstrated by timing `hg debugdeltachain -m` for the mozilla-central repo: $ time hg debugdeltachain -m > /dev/null before: 1057.4s after: 503.3s PyPy2.7 5.8.0: 220.0s It's worth noting that the C code isn't as optimal as it could be. We're still instantiating a new PyObject for every revision. A future optimization would be to reuse the PyObject on the cached index tuple. We could potentially also get wins by using a memory array of raw integers. There is also room for a delta chain cache on revlog instances. Of course, the best optimization is to implement revlog reading outside of Python so Python doesn't need to be concerned about the relatively expensive index entries and operations on them.

help: cleanup grammar in the hooks section

merge with i18n

revlog: backed out changeset e9d325cfe071 We'll move this to the default branch.

i18n-pt_BR: synchronized with efebc9f52ecb

config: register the 'devel.strip-obsmarkers' config The single explicit default that existed so far is converted to registered config value.

config: register the 'devel.serverrequirecert' config

config: register the 'devel.serverexactprotocol' config

config: register the 'devel.servercafile' config

config: register the 'devel.disableloaddefaultcerts' config

config: register the 'devel.check-relroot' config

config: register the devel.check-locks config

config: register the 'devel.bundle2.debug' config Existing explicit default are dropped now that the default is centralised.

config: register the 'devel.all-warnings' config Let us start registering the existing option. I'm starting with the 'devel' section because it is full of useful things that are poorly documented. So registering these will more than other section.

rebase: always pass destination as revnum to _handleskippingobsolete() We were passing it as a revision number in one place and as a context in another. It worked because the only use was in "repo[dest].rev()", but it was confusing. By always passing a revision number, we can also remove that unnecessary lookup.

patch: remove unused fsbackend._join() The function lost its last caller in 2a095d3442e0 (patch: replace functions in fsbackend to use vfs, 2014-06-05) when the callers started relying on the opener to do the join.

patch: add close() to abstractbackend patchbackend() seems to call it on an arbitrary backend, so it seems to be part of the API. Since all subclasses do something in their close() methods, I decided to let this one raise an exception rather than just pass.

log: add an extension hook-point in changeset_printer Extensions sometimes wants to add other information in the default log output format (when no templating is used). Add an empty function named '_exthook' for easing the extension life. Extensions will be able to wrap this function and collaborate to display additional information. Exthook is called after displaying troubles and just before displaying the files, extra and description. Add a new test file to test it and not pollute other test files.

drawdag: support obsmarker creation in comments This patch adds special comment handling so one can create obsmarkers in drawdag comments like "# replace: A -> B -> C", "# prune: X, Y, Z", "split: P -> M, N" and they are just self-explained.

test-drawdag: add a test for drawdag.py The drawdag script is useful but does not have a formal test. This patch adds it.

filemerge: convert a couple of wvfs calls in internal mergetools to contexts One hitch is that sometimes fcd is actually an absentfilectx which does not expose any mutator functions. In order to still use the context functions, we look up the underlying workingfilectx to perform the write there. One alternate way would be to put the write functions on the absentfilectx and have them pass-through. While this makes the callsites cleaner, we would need to decide what its getter functions would return after this point, since returning None for `data` (and True for `isabsent()`) might no longer be correct after a write. I discussed with Sidd about just having the getters raise RuntimeErrors after a mutator has been called, but we actually call isabsent() in merge.py after running the internal merge tools.

configitems: support callable as a default value Yuya pointed out that using mutable value as the default could be problematic. To work around this we now support callable object as default value. This allows for creating new mutable objects on demand when needed.

obsutil: move 'getmarkers' to the new modules We have a new 'obsutil' module now. We move the high level utility there to bring 'obsolete.py' back to a more reasonable size.

obsutil: move the 'marker' class to the new modules We have a new 'obsutil' module now. We move high level utility there to bring 'obsolete.py' back to a more reasonable size.

obsolete: delete three unused utility functions None of this function has been used in the past 5 years, so I think it is safe to just kill them. All code accessing rich markers is using 'getmarkers(...)' instead (or raw markers).