- Aug 15, 2018
-
-
Boris Feld authored
The `filelog` object is no longer an actual revlog. Instead, the actual revlog is stored in the `_revlog` attribute.
-
- Aug 17, 2018
-
-
Gregory Szorc authored
-
Boris Feld authored
Changeset 88efb7d6bcb6 introduced a performance regression by triggering a full ancestors walk. This changeset reworks this logic so that we no longer walk down the full changelog. The motivation for 88efb7d6bcb6, issue5939, is still fixed. mercurial compared to a draft repository ---------------------------------------- 8eeed92475d5: 0.012637 seconds 88efb7d6bcb6: 0.202699 seconds (x16) 46da52f4b820: 0.215551 seconds (+6%) this code: 0.008397 seconds (-33% from base) The payload size reduction we see in `test-bookmarks-pushpull.t` comes from a more aggressive filter of nullid and is harmless.
-
Kyle Lippincott authored
We just encountered `000000000000modified`, and it was quite annoying to search for these, even though I knew they existed. For those that don't know that they exist, this is essentially impossible to search for :) (Technically we encountered it in its hex form, 3030303030303030303030306d6f646966696564, so I'm adding comments with those forms in case that's helpful to people in the future). Differential Revision: https://phab.mercurial-scm.org/D4331
-
Yuya Nishihara authored
Just for clarity. This doesn't matter in practice since changelog.nodemap is accessed *before* filtered revisions get ready.
-
Yuya Nishihara authored
This bug was revealed by a3dacabd476b and a1f934573c0b.
-
Yuya Nishihara authored
It's been there since 2012, "clfilter: introduce `filteredrevs` attribute on changelog." I don't think we can apply changelog filtering to nodemap at this level, so this patch removes the nodemap stub completely.
-
Boris Feld authored
Changeset 88efb7d6bcb6 fixed the logic of `phases.newheads` but greatly regressed its performance (up to many order of magnitude). The first step to fix the regression is to exit early when there is no work to do. If there are no heads to filter or not roots to filter them, we don't have to do any work. This fixes the regression when talking to an all public changeset. The performance is even better than before. pypy, compared to an all public repo ------------------------------------ 8eeed92475d5: 0.005758 seconds 88efb7d6bcb6: 0.602517 seconds (x104) this code: 0.001508 seconds (-74% from base) mercurial compared to an all public repo ---------------------------------------- 8eeed92475d5: 0.000577 seconds 88efb7d6bcb6: 0.185316 seconds (x321) this code: 0.000150 seconds (-74% from base) The performance of newheads, when actual computations are required, is fixed in the next changeset.
-
Boris Feld authored
This command measure the time we spend analysing remote phase during push and pull and display some information relevant to this computation. The `test-contrib-perf.t` expected output has to be updated but I do need these module for this perf command.
-
- Aug 15, 2018
-
-
Boris Feld authored
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).
-
- Aug 17, 2018
-
-
Yuya Nishihara authored
Follows up 2a4bfbb52111. This is required for httprangereader, which is not an iterable itself.
-
Yuya Nishihara authored
Follows up 2a4bfbb52111.
-
Yuya Nishihara authored
Follows up 2a4bfbb52111.
-
Yuya Nishihara authored
Nothing passed before e9e742bd0501.
-
Yuya Nishihara authored
-
- Aug 16, 2018
-
-
Gregory Szorc authored
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 authored
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 authored
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 authored
Differential Revision: https://phab.mercurial-scm.org/D4298
-
- Jul 25, 2018
-
-
Augie Fackler authored
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 authored
This hasn't been maintained in a while, it looks like. Differential Revision: https://phab.mercurial-scm.org/D4289
-
- Aug 16, 2018
-
-
Kyle Lippincott authored
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
-
- Aug 14, 2018
-
-
Katsunori FUJIWARA authored
This information is useful to know which internal merge tools can be applied safely on binary files and/or symlinks.
-
- Aug 15, 2018
-
-
Katsunori FUJIWARA authored
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.
-
Katsunori FUJIWARA authored
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.
-
- Aug 14, 2018
-
-
Katsunori FUJIWARA authored
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".
-
Katsunori FUJIWARA authored
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.
-
Katsunori FUJIWARA authored
"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.
-
- Aug 16, 2018
-
-
durin42 authored
Differential Revision: https://phab.mercurial-scm.org/D4296
-
durin42 authored
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
-
durin42 authored
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
-
durin42 authored
Differential Revision: https://phab.mercurial-scm.org/D4293
-
- Aug 15, 2018
-
-
Sushil Khanchi authored
To prevent it from being updated by another process `restorestatus()` is moved under lock. Differential Revision: https://phab.mercurial-scm.org/D4282
-
- Aug 13, 2018
-
-
Martijn Pieters authored
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 authored
Differential Revision: https://phab.mercurial-scm.org/D4280
-
- Aug 16, 2018
-
-
Gregory Szorc authored
This drops the number of failures with this extension to 3. Differential Revision: https://phab.mercurial-scm.org/D4286
-
Gregory Szorc authored
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
-
- Jul 07, 2018
-
-
Yuya Nishihara authored
This is all for commit reproducibility on "hg convert". With this change, p1 manifest is reused if ctx.files() *to be committed* is empty, and if new manifest entry is identical to p1. This is important property for "hg convert" since memctx.files() built from a convert source may be either a) more narrowed thanks to a committed ctx.files() which provides more accurate status, or b) containing redundant files because of sloppy filtering on e.g. octopus merge.
-
- Aug 12, 2018
-
-
Yuya Nishihara authored
It isn't easy to say when to reuse the p1 manifest. Basically, that's only when wctx.files() is empty, but we need to know that wctx.files() is not the same as repo['.'].files() after the commit. This patch adds several examples of commits with empty ctx/wctx.files(). I don't think this is exhaustive, but it contains at least one failure mode in which a converted repo result in a different hash. I also note that the manifest revlog does NOT follow the DAG shape of the changelog since p1 manifest is reused if wctx.files() is empty even at merge. I don't know whether it is intentional or not, but it's the behavior since 2011, 301725c3df9a "localrepo: reuse parent manifest in commitctx if no files have changed."
-
- Jul 07, 2018
-
-
Yuya Nishihara authored
-