Boris Feld <boris.feld@octobus.net> [Thu, 23 Aug 2018 01:15:19 +0200] rev 39273
phase: handle phase with no command flag
Before this changeset, all existing phases have a corresponding flag on the `hg
phase` command. (eg: `hg phase --draft`).
After this changeset, a phase can exists without having an associated flag.
This is useful to introduce a new internal phase that we do not want to expose
to user.
Boris Feld <boris.feld@octobus.net> [Tue, 05 Jun 2018 20:47:52 +0200] rev 39272
phase: explicitly exclude secret phase and above
The comment explicitly mention the secret phase so we should as well use that in
the code.
Boris Feld <boris.feld@octobus.net> [Tue, 05 Jun 2018 18:16:07 +0200] rev 39271
phase: use `trackedphases` in `_getphaserevsnative`
Instead of manually listing secret and draft, simply use the `trackedphases`
constant. The constant is already used by `_getphaserevsnative`.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 24 Aug 2018 17:45:46 -0400] rev 39270
lfs: add a progress bar when searching for blobs to upload
The search itself can take an extreme amount of time if there are a lot of
revisions involved. I've got a local repo that took 6 minutes to push 1850
commits, and 60% of that time was spent here (there are ~70K files):
\ 58.1% wrapper.py: extractpointers line 297: pointers = extractpointers(...
| 57.7% wrapper.py: pointersfromctx line 352: for p in pointersfromctx(ct...
| 57.4% wrapper.py: pointerfromctx line 397: p = pointerfromctx(ctx, f, ...
\ 38.7% context.py: __contains__ line 368: if f not in ctx:
| 38.7% util.py: __get__ line 82: return key in self._manifest
| 38.7% context.py: _manifest line 1416: result = self.func(obj)
| 38.7% manifest.py: read line 472: return self._manifestctx.re...
\ 25.6% revlog.py: revision line 1562: text = rl.revision(self._node)
\ 12.8% revlog.py: _chunks line 2217: bins = self._chunks(chain, ...
| 12.0% revlog.py: decompressline 2112: ladd(decomp(buffer(data, ch...
\ 7.8% revlog.py: checkhash line 2232: self.checkhash(text, node, ...
| 7.8% revlog.py: hash line 2315: if node != self.hash(text, ...
| 7.8% revlog.py: hash line 2242: return hash(text, p1, p2)
\ 12.0% manifest.py: __init__ line 1565: self._data = manifestdict(t...
\ 16.8% context.py: filenode line 378: if not _islfs(fctx.filelog(...
| 15.7% util.py: __get__ line 706: return self._filelog
| 14.8% context.py: _filelog line 1416: result = self.func(obj)
| 14.8% localrepo.py: file line 629: return self._repo.file(self...
| 14.8% filelog.py: __init__ line 1134: return filelog.filelog(self...
| 14.5% revlog.py: __init__ line 24: censorable=True)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 22 Aug 2018 14:37:56 +0900] rev 39269
i18n: merge i18n comments of translatable texts correctly
Before this patch, i18n comments of translatable texts are lost at
creation of hg.pot file, if:
- same translatable text appears multiple times,
- the 1st appearance does not have i18n comment, and
- any of rest has it
For example, previous patch for filemerge.py adds translatable texts
with i18n comments, but these comments are lost, because:
- automatically added texts in docstring of internal merge tools are
picked up earlier than these translatable texts, because of
location in filemerge.py
- but docstring has no i18n comment
This patch makes addentry() of posplit merge i18n comments of later
translatable texts, in order to keep them at creation of hg.pot.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 22 Aug 2018 14:22:59 +0900] rev 39268
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 39267
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 39266
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 39265
merge with stable
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 24 Aug 2018 18:21:55 -0700] rev 39264
scmutil: avoid quadratic membership testing (
issue5969)
tr.changes['revs'] is an xrange, which has an O(n) __contains__
implementation. The `rev not in newrevs` lookup a few lines below
will therefore be O(n^2) if all incoming changesets are public.
This issue isn't present on @ because
45e05d39d9ce introduced
a custom type implementing an xrange primitive with O(1) contains
and switched tr.changes['revs'] to be an instance of that type.
We work around the problem on the stable branch by casting the
xrange to a set. This is a bit hacky because it requires allocating
memory to hold each integer in the range. But we are already
holding the full set of pulled revision numbers in memory
multiple times (such as in `tr.changes['phases']`). So this is
a relatively minor problem.
This issue has been present since the phases reporting code was
introduced in the 4.7 cycle by
eb9835014d20.
This change should be reverted/ignored when stable is merged into
default.
On the mozilla-unified repository with 483492 changesets, `hg clone`
time improves substantially:
before: 1843.700s user; 29.810s sys
after: 461.170s user; 29.360s sys