Boris Feld <boris.feld@octobus.net> [Wed, 15 Aug 2018 14:43:40 +0200] rev 39139
sparse-revlog: fix delta validity computation
When considering the validity of a delta with sparse-revlog, we check the size
of the largest read. To do so, we use some regular logic with the extra delta
information. Some of this logic was not handling this extra delta properly,
confusing it with "nullrev". This confusion with nullrev lead to wrong results
for this computation but preventing a crash.
Changeset
781b2720d2ac on default revealed this error, crashing. This
changeset fixes the logic on stable so that the computation is correct (and
the crash is averted).
The fix is made on stable as this will impact 4.7 clients interacting with
sparse-revlog repositories (eg: created by later version).
Yuya Nishihara <yuya@tcha.org> [Fri, 17 Aug 2018 10:51:05 +0900] rev 39138
branchmap: explicitly convert file into iterator
Follows up
2a4bfbb52111. This is required for httprangereader, which is not
an iterable itself.
Yuya Nishihara <yuya@tcha.org> [Fri, 17 Aug 2018 10:25:39 +0900] rev 39137
branchmap: close cache file properly
Follows up
2a4bfbb52111.
Yuya Nishihara <yuya@tcha.org> [Fri, 17 Aug 2018 10:24:29 +0900] rev 39136
branchmap: strip '\n' read from cache file as before
Follows up
2a4bfbb52111.
Yuya Nishihara <yuya@tcha.org> [Fri, 17 Aug 2018 10:21:25 +0900] rev 39135
rebase: do not pass in user option to rollback in-memory merge conflict
Nothing passed before
e9e742bd0501.
Yuya Nishihara <yuya@tcha.org> [Fri, 17 Aug 2018 10:19:17 +0900] rev 39134
rebase: add test for in-memory merge conflicts
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 16 Aug 2018 18:53:51 +0000] rev 39133
rebase: call _dorebase() properly
This fixes a regression from
e9e742bd0501 where we failed to pass
all necessary arguments to _dorebase().
Differential Revision: https://phab.mercurial-scm.org/D4302
Pulkit Goyal <pulkit@yandex-team.ru> [Thu, 16 Aug 2018 16:59:40 +0300] rev 39132
context: make sure file is not deleted while checking path conflicts
If a file is deleted and a directory of same name is created in the same commit,
IMM thinks of that as a file conflict, however the file is deleted and hence the
directory can be created.
The test change demonstrate the fix.
Differential Revision: https://phab.mercurial-scm.org/D4300
Pulkit Goyal <pulkit@yandex-team.ru> [Thu, 16 Aug 2018 16:53:48 +0300] rev 39131
tests: demonstrate that IMM needs to be smarter with path conflicts
When we try to rebase a commit which deletes an existing file and make a
directory of the same name, rebase with IMM aborts. It should work fine just
like the without IMM case.
Differential Revision: https://phab.mercurial-scm.org/D4299
Pulkit Goyal <pulkit@yandex-team.ru> [Thu, 16 Aug 2018 16:36:32 +0300] rev 39130
tests: don't create new repo inside existing repo in test-rebase-inmemory.t
Differential Revision: https://phab.mercurial-scm.org/D4298
Augie Fackler <augie@google.com> [Wed, 25 Jul 2018 13:40:42 -0400] rev 39129
tests: remove test-py3-commands.t
This was a smoke test for early in the Python 3 porting effort, before
anything actually worked. Now that we've got over half the testsuite
passing, this test has outlived its utility.
Differential Revision: https://phab.mercurial-scm.org/D4288
Augie Fackler <augie@google.com> [Wed, 25 Jul 2018 13:41:21 -0400] rev 39128
tests: update test-check-py3-compat.t output in the py3exe branch
This hasn't been maintained in a while, it looks like.
Differential Revision: https://phab.mercurial-scm.org/D4289
Kyle Lippincott <spectral@google.com> [Wed, 15 Aug 2018 17:40:21 -0700] rev 39127
overlayworkingctx: fix exception in metadata-only inmemory merges (
issue5960)
If there was a metadata-only mutation, such as +x or -x on a file, we would
create a cache entry with None for data, and this would cause problems later on
when some code tried to run fctx.data() or similar, and was expecting a string.
My original fix for this involved passing data=self._wrappedctx[path].data() in
setflags(), but this version seems slightly better - this way, if we ever call
write() and then call setflags(), we don't destroy the data that we wrote that's
in the cache. I haven't verified that other fields aren't destroyed, such as
date or flags :)
Differential Revision: https://phab.mercurial-scm.org/D4287
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 14 Aug 2018 22:20:28 +0900] rev 39126
filemerge: show actual capabilities of internal merge tools
This information is useful to know which internal merge tools can be
applied safely on binary files and/or symlinks.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 15 Aug 2018 22:24:50 +0900] rev 39125
filemerge: add config knob to check capabilities of internal merge tools
For historical reason, Mercurial assumes capabilities of internal
merge tools as below while examining rules to decide merge tool,
regardless of actual capabilities of them.
=============== ====== ========
specified via binary symlinks
=============== ====== ========
--tool o o
HGMERGE o o
merge-patterns o (*) x (*)
ui.merge x (*) x (*)
=============== ====== ========
This causes:
- unintentional internal merge tool is chosen for binary files via
merge-patterns section of configuration file
- explicit configuration of internal merge tool for symlinks is
ignored unintentionally
But on the other hand, simple "check capability strictly" might break
backward compatibility (e.g. existing merge automations), because it
changes the result of merge tool selection.
Therefore, this patch adds config knob "merge.strict-capability-check"
to control whether capabilities of internal merge tools should be
checked strictly or not.
If this configuration is true, capabilities of internal merge tools
are checked strictly in (*) cases above.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 15 Aug 2018 22:24:38 +0900] rev 39124
filemerge: show warning if chosen tool has no binary files capability
While matching patterns in "merge-patterns" configuration, Mercurial
silently assumes that all merge tools have binary files
capability. This implementation comes from
5af5f0f9d724 (or Mercurial
1.0).
At failure of merging binary files with incorrect internal merge tool,
there is no hint about this silent ignorance of binary files
capability.
This patch shows warning message, if chosen internal merge tool has no
binary files capability. This will help users to investigate why a
binary file isn't merged as expected.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 14 Aug 2018 20:15:51 +0900] rev 39123
filemerge: add the function to examine a capability of a internal tool
For "symlink" and "binary" capabilities, _toolbool() can not examine
these of internal merge tools strictly, because it examines only
configurations in "merge-tools" section.
Users can configure them explicitly as below for example, but this is
not ordinary usage and not convenient:
[merge-tools]
:other.symlink = true
:other.binary = true
This patch adds hascapability() internal function, which can examine
actual capabilities of a internal merge tool strictly.
At this patch, hascapability() is still used with "strict=False".
Subsequent patches use it with "strict=True".
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 14 Aug 2018 20:08:27 +0900] rev 39122
filemerge: set actual capabilities of internal merge tools
This information is used to detect actual capabilities of internal
merge tools by subsequent patches.
For convenience, this patch assumes that merge tools typed as
"nomerge" have both binary files and symlinks capabilities.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 14 Aug 2018 20:05:36 +0900] rev 39121
help: describe more detail about capabilities while deciding merge tool
"hg help merge-tools" describes as below:
(internal merge tools) will by default not handle symlinks or
binary files.
But in some cases, Mercurial assumes that internal merge tools have
one or both of these capabilities.
"hg help merge-tools" also describes as below, for matching patterns in
merge-patterns configuration section. But this is not sufficient.
Here, binary capabilities of the merge tool are not considered.
This patch describes more detail about capabilities while deciding
merge tool.
Augie Fackler <raf@durin42.com> [Thu, 16 Aug 2018 00:50:53 -0400] rev 39120
tests: un-glob patchbomb test lines that were only globbing a hostname
Differential Revision: https://phab.mercurial-scm.org/D4296
Augie Fackler <raf@durin42.com> [Thu, 16 Aug 2018 00:42:04 -0400] rev 39119
tests: force a stable hostname in patchbomb tests
No visible output changes in this commit because everything is globbed
away, but on Python 3 the stable hostname will mean that the headers
don't trigger RFC2822 multi-line mode because they'll always be
consistently short.
Differential Revision: https://phab.mercurial-scm.org/D4295
Augie Fackler <raf@durin42.com> [Thu, 16 Aug 2018 00:40:20 -0400] rev 39118
patchbomb: allow using HGHOSTNAME to force a hostname
I'll update run-tests.py to set this globally to stabilize some
tests. The variable name is intentionally generic because I suspect we
should generalize this to other tests.
Differential Revision: https://phab.mercurial-scm.org/D4294
Augie Fackler <raf@durin42.com> [Thu, 16 Aug 2018 00:39:32 -0400] rev 39117
patchbomb: extract function for generating message-id
Differential Revision: https://phab.mercurial-scm.org/D4293
Sushil khanchi <sushilkhanchi97@gmail.com> [Wed, 15 Aug 2018 11:27:57 +0530] rev 39116
rebase: cover restorestatus() by lock to prevent it from being updated
To prevent it from being updated by another process
`restorestatus()` is moved under lock.
Differential Revision: https://phab.mercurial-scm.org/D4282
Martijn Pieters <mj@octobus.net> [Mon, 13 Aug 2018 21:22:14 +0100] rev 39115
branchmap: load branchmap as an iterable
This avoids reading all the file into memory if the cache turns out to be
invalid.
Differential Revision: https://phab.mercurial-scm.org/D4281
Martijn Pieters <mj@octobus.net> [Mon, 13 Aug 2018 20:31:01 +0100] rev 39114
perf: time loading branchmap caches
Differential Revision: https://phab.mercurial-scm.org/D4280
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 16 Aug 2018 00:13:41 +0000] rev 39113
tests: add conditional output when simplestore extensions is loaded
This drops the number of failures with this extension to 3.
Differential Revision: https://phab.mercurial-scm.org/D4286
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 16 Aug 2018 00:11:35 +0000] rev 39112
tests: conditionalize extension tests for extra extensions
If extra extensions are loaded (e.g. via --extra-config-opt),
the tests conditionalized in this commit fail in ways that
are dependent on the extensions that are loaded. So let's
skip them when that scenario is present.
This drops the number of failures for the simplestorerepo.py
extension to 4.
Differential Revision: https://phab.mercurial-scm.org/D4285