Wed, 22 Aug 2018 14:22:59 +0900 help: revise explanation about capability check while selecting merge tool
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 22 Aug 2018 14:22:59 +0900] rev 39295
help: revise explanation about capability check while selecting merge tool This is follow up of 7c6044634957 and cded904f7acc. This patch adds explanations about: - notation in capability columns in the table - how capabilities of external merge tools are treated
Wed, 22 Aug 2018 14:08:27 +0900 filemerge: avoid putting translated text into docstring
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 22 Aug 2018 14:08:27 +0900] rev 39294
filemerge: avoid putting translated text into docstring This is follow up of my mistake in e09fad982ef5. There is no merge tool, which has only one of binary or symlink capabilities, but this patch lists up all combinations of them for safety in the future. Maybe, it is too paranoid, though.
Wed, 22 Aug 2018 13:57:01 +0900 filemerge: make capability check for internal tools ignore merge-tools section
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 22 Aug 2018 13:57:01 +0900] rev 39293
filemerge: make capability check for internal tools ignore merge-tools section This is follow up of 4d7b11877dd0. Before this patch, capability check of internal merge tools falls back to _toolbool(), which examines configurations in "merge-tools" section. But "hg help config" explicitly says that "merge-tools" section configures external merge tools. Therefore, this patch makes capability check for internal tools in hascapability() always ignore configurations in merge-tools section. In this patch, command line configurations below are added at tests in tests/test-merge-tools.t, in order to confirm that explicit configuration is intentionally ignored at tool selection. --config merge-tools.:INTERNAL_TOOL.CAPABILITY=true
Fri, 24 Aug 2018 22:21:04 -0700 merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Aug 2018 22:21:04 -0700] rev 39292
merge with stable
Wed, 15 Aug 2018 14:41:27 -0700 copies: correctly skip directories that have already been considered
Kyle Lippincott <spectral@google.com> [Wed, 15 Aug 2018 14:41:27 -0700] rev 39291
copies: correctly skip directories that have already been considered Previously, `if dsrc in invalid` would never be true, since we added `dsrc +"/"` to invalid, not `dsrc` itself. Since it's much more common for individual files (not whole directories) to be moved, it seemed cleaner to delay appending the "/" until we know we have some directory moves to actually consider. I haven't benchmarked this, but I imagine this is a mild performance win. Differential Revision: https://phab.mercurial-scm.org/D4284
Fri, 24 Aug 2018 12:55:05 -0700 merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Aug 2018 12:55:05 -0700] rev 39290
merge with stable
Fri, 24 Aug 2018 10:19:31 -0700 match: make exactmatcher.visitchildrenset return file children as well
Kyle Lippincott <spectral@google.com> [Fri, 24 Aug 2018 10:19:31 -0700] rev 39289
match: make exactmatcher.visitchildrenset return file children as well Previously, if we had an exactmatcher like ['foo.txt', 'a/bar.txt', 'a/b/c/baz.txt'], we'd get back the following data: '.': {'a'} 'a': {'b'} 'a/b': {'c'} 'a/b/c': 'this' 'a/b/c/d': set() This was incorrect, since visitchildrenset explicitly says not to pay attention to 'foo.txt' and 'a/bar.txt' by not returning them or 'this'. Given the near impossibility of making visitchildrenset reliabbly produce only subdirectories, a previous commit has made it documented and expected that visitchildrenset can return a set containing both files and subdirectories to visit, instead of implying/requiring that visitchildrenset() return 'this' if there are files to visit. This makes the code for exactmatcher match this clarified documentation. Differential Revision: https://phab.mercurial-scm.org/D4365
Thu, 23 Aug 2018 18:04:15 -0700 match: document that visitchildrenset might return files
Kyle Lippincott <spectral@google.com> [Thu, 23 Aug 2018 18:04:15 -0700] rev 39288
match: document that visitchildrenset might return files At least when using includematcher, and probably most matchers, we do not know if a/b/f refers to a file 'f' in a/b, or a subdirectory 'f' in a/b, so most matchers will return {'f'} for visitchildrenset('a/b'). Arguably, all matchers could/should - for exactmatcher, we know that 'f' is a file, but there's no reason to return 'this' for visitchildrenset('a/b') causing code to investigate 'a/b/x', for example. Differential Revision: https://phab.mercurial-scm.org/D4364
Fri, 24 Aug 2018 10:13:27 -0700 util: make timedcm require the label (API)
Augie Fackler <augie@google.com> [Fri, 24 Aug 2018 10:13:27 -0700] rev 39287
util: make timedcm require the label (API) Differential Revision: https://phab.mercurial-scm.org/D4350
Tue, 21 Aug 2018 17:15:51 -0400 cleanup: make all uses of timedcm specify what they're timing
Augie Fackler <augie@google.com> [Tue, 21 Aug 2018 17:15:51 -0400] rev 39286
cleanup: make all uses of timedcm specify what they're timing It's not used in the timing itself, but it's valuable for the trace events we emit. Differential Revision: https://phab.mercurial-scm.org/D4349
Tue, 21 Aug 2018 17:13:35 -0400 util: make timedcm context manager also emit trace events
Augie Fackler <augie@google.com> [Tue, 21 Aug 2018 17:13:35 -0400] rev 39285
util: make timedcm context manager also emit trace events Differential Revision: https://phab.mercurial-scm.org/D4348
Tue, 21 Aug 2018 15:27:30 -0400 demandimport: instrument python 2 code with trace events
Augie Fackler <augie@google.com> [Tue, 21 Aug 2018 15:27:30 -0400] rev 39284
demandimport: instrument python 2 code with trace events This causes the evaluation of an import in Python 3 to emit some trace data. There's some interesting wrinkles in here, like the fact that before we even hit dispatch we've demand-imported `sys` several times, despite the fact that `sys` was already fully loaded as one of the first few statements in the `hg` script. I don't think that's actually costing us a ton of performance, but it's probably something we should investigate fixing some day. Differential Revision: https://phab.mercurial-scm.org/D4347
Tue, 21 Aug 2018 15:25:07 -0400 dispatch: have dispatch.dispatch and dispatch._runcatch emit trace events
Augie Fackler <augie@google.com> [Tue, 21 Aug 2018 15:25:07 -0400] rev 39283
dispatch: have dispatch.dispatch and dispatch._runcatch emit trace events Differential Revision: https://phab.mercurial-scm.org/D4345
Tue, 21 Aug 2018 15:24:20 -0400 tracing: new module to make tracing events in hg easier
Augie Fackler <augie@google.com> [Tue, 21 Aug 2018 15:24:20 -0400] rev 39282
tracing: new module to make tracing events in hg easier This lives in hgdemandimport because I want to instrument a bunch of low-level stuff including the bare `hg` script and demandimport, so it can't live at a higher layer. Differential Revision: https://phab.mercurial-scm.org/D4344
Tue, 21 Aug 2018 15:23:01 -0400 tests: add support for emitting trace events to run-tests
Augie Fackler <augie@google.com> [Tue, 21 Aug 2018 15:23:01 -0400] rev 39281
tests: add support for emitting trace events to run-tests Right now this is pretty basic, but it's a start. Differential Revision: https://phab.mercurial-scm.org/D4343
Tue, 21 Aug 2018 15:01:09 -0400 contrib: new script to read events from a named pipe and emit catapult traces
Augie Fackler <augie@google.com> [Tue, 21 Aug 2018 15:01:09 -0400] rev 39280
contrib: new script to read events from a named pipe and emit catapult traces I'm starting to get more serious about getting some insight into where we're spending our time, both in hg itself but also in the test suite. As a first pass, I'm going to try and produce catapult traces[0] that can be viewed with Chrome's `about:tracing` tool. 0: https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/edit#heading=h.nso4gcezn7n1 Differential Revision: https://phab.mercurial-scm.org/D4342
Tue, 21 Aug 2018 22:49:08 -0400 fastannotate: pconvert paths from the server for Windows
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Aug 2018 22:49:08 -0400] rev 39279
fastannotate: pconvert paths from the server for Windows I'm guessing that the right thing to do here is to convert the paths on the server, but I know this is a WIP, and I don't know where that needs to happen. I'm just trying to eliminate the malicious path warnings in the tests.
Tue, 21 Aug 2018 22:34:32 -0400 test-fastannotate: close fd before unlinking to keep Windows happy
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Aug 2018 22:34:32 -0400] rev 39278
test-fastannotate: close fd before unlinking to keep Windows happy
Tue, 21 Aug 2018 21:43:44 -0400 test-fastannotate: fix trivial output differences on Windows
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Aug 2018 21:43:44 -0400] rev 39277
test-fastannotate: fix trivial output differences on Windows
Tue, 21 Aug 2018 21:29:10 -0400 fastannotate: make the default value for `fastannotate.useflock` dynamic
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Aug 2018 21:29:10 -0400] rev 39276
fastannotate: make the default value for `fastannotate.useflock` dynamic fcntl.flock isn't available on Windows.
Wed, 08 Aug 2018 13:56:53 +0300 narrow: add a --narrowspec flag to clone command
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 08 Aug 2018 13:56:53 +0300] rev 39275
narrow: add a --narrowspec flag to clone command This patch adds a --narrowspec flag to `hg clone` command in narrow extension which can be used to read a file and parse narrowspecs from it and use it while cloning a repository. The --narrowspec flag assumes that the user wanted to narrow the clone. Tests are added both for ellipsis and non-ellipsis mode. Differential Revision: https://phab.mercurial-scm.org/D4156
Fri, 10 Aug 2018 16:01:19 -0700 manifest: use rev() instead of nodemap.__contains__
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 10 Aug 2018 16:01:19 -0700] rev 39274
manifest: use rev() instead of nodemap.__contains__ nodemap is an implementation detail of revlogs and isn't appropriate to expose on the manifest storage API. While revlogs don't have a __contains__, they do have lookup() for resolving a value to a node. And this calls rev(), whose API is documented to raise LookupError if a node doesn't exist. And the parameters to LookupError are identical to what was being raised here. So this change should be backwards compatible. Differential Revision: https://phab.mercurial-scm.org/D4279
Fri, 10 Aug 2018 15:06:41 -0700 manifest: rename manifestlog._treeinmem to ._treemanifests
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 10 Aug 2018 15:06:41 -0700] rev 39273
manifest: rename manifestlog._treeinmem to ._treemanifests Not sure what "inmem" was supposed to indicate. This object is an interface to manifest data on disk as well as "in memory" (assuming that's what "inmem" means). Differential Revision: https://phab.mercurial-scm.org/D4278
Fri, 10 Aug 2018 15:01:06 -0700 manifest: add getstorage() to manifestlog and use it globally
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 10 Aug 2018 15:01:06 -0700] rev 39272
manifest: add getstorage() to manifestlog and use it globally It is a common pattern to obtain a directory manifest storage instance (a manifestrevlog) by going through manifestlog._revlog.dirlog(). Why access to storage and caching of other manifests is done through manifestrevlog instead of manifestlog, I don't know. This commit establishes a getstorage(tree) API on manifestlog and imanifestlog that provides a public API for accessing manifest storage. All consumers previously using private attributes have been updated to use this new method. .. api:: manifestlog now has a getstorage(tree) method It should be used for obtaining an object representing the manifest's storage implementation. Accessing manifestlog._revlog should be avoided. Differential Revision: https://phab.mercurial-scm.org/D4277
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 +3000 +10000 tip