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
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.
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
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Aug 2018 22:21:04 -0700] rev 39292
merge with stable
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
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Aug 2018 12:55:05 -0700] rev 39290
merge with stable
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
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
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
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
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
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
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
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
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
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
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.
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
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Aug 2018 21:43:44 -0400] rev 39277
test-fastannotate: fix trivial output differences on Windows
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.
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
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
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
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