Fri, 06 Oct 2017 16:23:47 +0200 ui: add the possibility to returns None as username in ui
Boris Feld <boris.feld@octobus.net> [Fri, 06 Oct 2017 16:23:47 +0200] rev 34849
ui: add the possibility to returns None as username in ui In a later patch we want to retrieve the current username or None if it isn't defined. Add the acceptempty parameter instead of catching Abort.
Fri, 06 Oct 2017 17:15:49 +0200 test: test obfate template keyword in test-obsmarker-template.t
Boris Feld <boris.feld@octobus.net> [Fri, 06 Oct 2017 17:15:49 +0200] rev 34848
test: test obfate template keyword in test-obsmarker-template.t These test updates are pretty big by themselves so put it in a separate patch for easing the review process.
Thu, 05 Oct 2017 17:42:56 +0200 templatekw: introduce obsfate keyword
Boris Feld <boris.feld@octobus.net> [Thu, 05 Oct 2017 17:42:56 +0200] rev 34847
templatekw: introduce obsfate keyword Introduce an obsfate printer that uses all helpers functions defined in obsutil to get all the obsfate-related data and format a string according to the current format in test-obsmarker-template.t. Then, introduce an obsfate templatekw that uses the obsfateprinter to return a list of strings. The goal is not to replace existing obsfate template functions but to propose a default, good-enough and easily usable obsfate definition for end-users that don't want to customize it. Such output would ultimately get included in the default log output. Here are some output examples for a commit amended: rewritten using amend as 5:a9b1f8652753 by test (at 1970-01-01 00:00 +0000) Next patches will make the output dependent on the verbosity. Exemple of use-cases: For having the obsfate on a single-line between brackets: {if(obsfate, " [{join(obsfate, "; ")}]")} For having the obsfate in several lines: {if(obsfate, "{obsfate % " Obsfate: {fate}\n"}")}
Tue, 10 Oct 2017 02:25:03 +0530 copies: add a config to limit the number of candidates to check in heuristics
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 10 Oct 2017 02:25:03 +0530] rev 34846
copies: add a config to limit the number of candidates to check in heuristics The heuristics algorithm find possible candidates for move/copy and then check whether they are actually a copy or move. In some cases, there can be lot of candidates possible which can actually slow down the algorithm. This patch introduces a config option `experimental.copytrace.movecandidateslimit` using which one can limit the candidates to check. The limit defaults to 100. Thanks to Yuya for suggesting to skip copytracing for that file with a warning. Differential Revision: https://phab.mercurial-scm.org/D987
Tue, 17 Oct 2017 10:31:44 -0700 extensions: always include traceback when extension setup fails
Martin von Zweigbergk <martinvonz@google.com> [Tue, 17 Oct 2017 10:31:44 -0700] rev 34845
extensions: always include traceback when extension setup fails I have spent a lot of time debugging extensions that failed to load because we don't include a traceback and I didn't realize I could get traceback for the extension failure with --traceback. Let's just turn them on by default, since it should be rare that the user sees these tracebacks anyway (and if they do, it's not so bad if the extra traceback pushes them a little harder to report the problem). Since we already had a test case with --traceback and one without, I just removed the one with the flag. Differential Revision: https://phab.mercurial-scm.org/D1164
Tue, 17 Oct 2017 10:25:32 -0700 tests: move baduisetup() test out of "#if demandimport"
Martin von Zweigbergk <martinvonz@google.com> [Tue, 17 Oct 2017 10:25:32 -0700] rev 34844
tests: move baduisetup() test out of "#if demandimport" It no longer depends on demandimport. Differential Revision: https://phab.mercurial-scm.org/D1163
Tue, 17 Oct 2017 09:46:31 -0700 tests: make test-extension.t's baduisetup.py test fail even if bdiff exists
Martin von Zweigbergk <martinvonz@google.com> [Tue, 17 Oct 2017 09:46:31 -0700] rev 34843
tests: make test-extension.t's baduisetup.py test fail even if bdiff exists A mercurial.bdiff module has existed at some point and when I have built at an old version, some .pyc file or something seems to stick around and test-extension.t fails. Let's remove the reference to bdiff and simplify the test. Differential Revision: https://phab.mercurial-scm.org/D1162
Tue, 17 Oct 2017 10:33:27 -0700 run-tests: move newline out of colorized message
Martin von Zweigbergk <martinvonz@google.com> [Tue, 17 Oct 2017 10:33:27 -0700] rev 34842
run-tests: move newline out of colorized message The leading newline before "ERROR:" led to an incorrect lexing of the message and the newline got lost. The fixed formatting can be seen in the test case. The reason we didn't notice before was that the bad formatting just led to the loss of a blank line in the test. However, there are other cases where it would be joined with a line saying "Accept this change? [n]" or "Reference output has changed (run again to prompt changes)". Differential Revision: https://phab.mercurial-scm.org/D1159
Tue, 17 Oct 2017 11:07:18 -0700 test-extension: make the test compatible with chg
Saurabh Singh <singhsrb@fb.com> [Tue, 17 Oct 2017 11:07:18 -0700] rev 34841
test-extension: make the test compatible with chg This test fails when run with chg. This commit just makes the test chg aware by fixing the output of some of the tests. Test Plan: Ran the test 'test-extension.t' with and without '--chg' option. Differential Revision: https://phab.mercurial-scm.org/D1160
Tue, 17 Oct 2017 11:35:58 -0700 hghave: disable demandimport when chg is running
Saurabh Singh <singhsrb@fb.com> [Tue, 17 Oct 2017 11:35:58 -0700] rev 34840
hghave: disable demandimport when chg is running Chg disables demandimport on purpose for performance wins and therefore, it probably makes sense to indicate that demandimport is disabled when chg is running. Test Plan: Ran all the tests. Differential Revision: https://phab.mercurial-scm.org/D1161
Tue, 17 Oct 2017 10:41:56 -0700 test-show: make it compatible with chg
Jun Wu <quark@fb.com> [Tue, 17 Oct 2017 10:41:56 -0700] rev 34839
test-show: make it compatible with chg The show extension reads `commands.show.aliasprefix` config in its `extsetup` and that causes issues with chg. This patch adds that config item to chg confighash to solve the issue. Test Plan: `run-tests.py -l --chg test-show.t` Differential Revision: https://phab.mercurial-scm.org/D1158
Tue, 17 Oct 2017 10:51:43 -0400 templater: use pycompat.sysbytes to bytes-ify some __name__ attrs
Augie Fackler <augie@google.com> [Tue, 17 Oct 2017 10:51:43 -0400] rev 34838
templater: use pycompat.sysbytes to bytes-ify some __name__ attrs Spotted by yuya in review of e87e62b7fc0b. Differential Revision: https://phab.mercurial-scm.org/D1145
Mon, 16 Oct 2017 22:44:43 -0400 templatefilters: defend against evil unicode strs in json filter
Augie Fackler <augie@google.com> [Mon, 16 Oct 2017 22:44:43 -0400] rev 34837
templatefilters: defend against evil unicode strs in json filter We only want to do I/O in terms of bytes, so lets explode early instead of recursing forever. Differential Revision: https://phab.mercurial-scm.org/D1136
Wed, 20 Sep 2017 19:38:06 +0200 phase: use a binary phase part to push through bundle2 (BC)
Boris Feld <boris.feld@octobus.net> [Wed, 20 Sep 2017 19:38:06 +0200] rev 34836
phase: use a binary phase part to push through bundle2 (BC) The part we are using for pull is now used for push too. As we no longer use pushkey, pushkey hooks are no longer triggered. This is an obvious backward incompatible change. We could artificially trigger the pushkey hook within the bundle2 part, but this seemed too hacky to me. An option would be to disable by default this new mechanism for a couple of versions to help people migrate to `txnclose-phase`. I took the liberal and optimistic path to just turn it on by default directly. .. bc:: Push no longer triggers a pushkey hook when updating phases. Use the new `txnclose-phase` and `txnclose-phase` hooks instead. (Applies when both server and client use version 4.4 or above).
Tue, 17 Oct 2017 12:41:24 -0700 arbitraryfilecontext: skip the cmp fast path if any side is a symlink
Phil Cohen <phillco@fb.com> [Tue, 17 Oct 2017 12:41:24 -0700] rev 34835
arbitraryfilecontext: skip the cmp fast path if any side is a symlink `filecmp` follows symlinks by default, which a `filectx.cmp()` call should not be doing as it should only compare the requested entry. After this patch, only the contexts' data are compared, which is the correct contract. This is a corrected version of D1122. Differential Revision: https://phab.mercurial-scm.org/D1165
Mon, 14 Sep 2015 14:17:27 -0400 test-clang-format: new test to verify that files stay clang-formatted
Augie Fackler <augie@google.com> [Mon, 14 Sep 2015 14:17:27 -0400] rev 34834
test-clang-format: new test to verify that files stay clang-formatted For now all .c and .h files are blacklisted. As they become clang-formatted, we'll remove them from the blacklist,and then this test will produce output if there are diffs. Differential Revision: https://phab.mercurial-scm.org/D1133
Tue, 17 Oct 2017 08:11:13 -0700 context: audit paths before clearing unknown files and dirs
Mark Thomas <mbthomas@fb.com> [Tue, 17 Oct 2017 08:11:13 -0700] rev 34833
context: audit paths before clearing unknown files and dirs Fix regression introduced in D785. In some circumstances, context.clearunknown can be called before the path is audited. Audit the path before deleting any conflicting files. Differential Revision: https://phab.mercurial-scm.org/D1157
Tue, 17 Oct 2017 08:07:43 -0700 tests: add test demonstrating regression in path audit
Mark Thomas <mbthomas@fb.com> [Tue, 17 Oct 2017 08:07:43 -0700] rev 34832
tests: add test demonstrating regression in path audit D785 regressed behavior in path auditing: files can be deleted if they have a path that conflicts with a filename from a malicious remote or bundle. This test demonstrates the problem - the file should not have been deleted. Differential Revision: https://phab.mercurial-scm.org/D1156
Fri, 13 Oct 2017 23:00:31 +0200 configitems: move rebase config into core
Boris Feld <boris.feld@octobus.net> [Fri, 13 Oct 2017 23:00:31 +0200] rev 34831
configitems: move rebase config into core The shelve extensions import and call rebase content without loading the extension. This is problematic as the config items rebase uses are not declared and the default value are not set, etc... The shelve extension should be using core utilities only and the necessary bit should be moved from rebase into core. In the meantime, I'm taking a small step to get config registration completed with minimal overhead. The rebase extension is shipped with core so registering its config option within core is not a big issue. This is the last step needed before we can install a warning that enforces all config to be registered.
Sat, 14 Oct 2017 01:09:46 +0200 eol: ensure the eol extensions is loaded when hooks run
Boris Feld <boris.feld@octobus.net> [Sat, 14 Oct 2017 01:09:46 +0200] rev 34830
eol: ensure the eol extensions is loaded when hooks run Similar to the change we did to the 'acl' extensions, we want to make sure the config items are registered before we run the hooks.
Sat, 14 Oct 2017 01:16:03 +0200 acl: make sure the extensions is enabled when the acl-hooks run
Boris Feld <boris.feld@octobus.net> [Sat, 14 Oct 2017 01:16:03 +0200] rev 34829
acl: make sure the extensions is enabled when the acl-hooks run The acl extension is usually setup through hooks and never directly activated. This means the config item declared in the extension are not loaded. We add the necessary logic to make sure the extensions are loaded before the hook run.
Mon, 16 Oct 2017 18:16:29 +0200 configitems: register the 'web.archivesubrepos' config
Boris Feld <boris.feld@octobus.net> [Mon, 16 Oct 2017 18:16:29 +0200] rev 34828
configitems: register the 'web.archivesubrepos' config
Sun, 08 Oct 2017 22:22:27 +0200 configitems: register the 'experimental.effect-flags' config
Boris Feld <boris.feld@octobus.net> [Sun, 08 Oct 2017 22:22:27 +0200] rev 34827
configitems: register the 'experimental.effect-flags' config
Sun, 08 Oct 2017 20:37:13 +0200 configitems: register the full 'merge-tools' config and sub-options
Boris Feld <boris.feld@octobus.net> [Sun, 08 Oct 2017 20:37:13 +0200] rev 34826
configitems: register the full 'merge-tools' config and sub-options We register the merge-tools config section (which has an arbitrary base config value) and the possible sub-attribute. The sub-attribute has to be registered first or at the same time otherwise the '.*' item would shadow them. Merge tools could include "." in their name so we can't constrain any more than just ".*".
Sat, 14 Oct 2017 17:05:41 +0200 revlog-sparse-read: add a lower-threshold for read block size
Paul Morelle <paul.morelle@octobus.net> [Sat, 14 Oct 2017 17:05:41 +0200] rev 34825
revlog-sparse-read: add a lower-threshold for read block size The option experimental.sparse-read.min-block-size specifies the minimal size of a deltachain span, under which it won't be split by _slicechunk.
Tue, 10 Oct 2017 17:50:27 +0200 revlog: introduce an experimental flag to slice chunks reads when too sparse
Paul Morelle <paul.morelle@octobus.net> [Tue, 10 Oct 2017 17:50:27 +0200] rev 34824
revlog: introduce an experimental flag to slice chunks reads when too sparse Delta chains can become quite sparse if there is a lot of unrelated data between relevant pieces. Right now, revlog always reads all the necessary data for the delta chain in one single read. This can lead to a lot of unrelated data to be read (see issue5482 for more details). One can use the `experimental.maxdeltachainspan` option with a large value (or -1) to easily produce a very sparse delta chain. This change introduces the ability to slice the chunks retrieval into multiple reads, skipping large sections of unrelated data. Preliminary testing shows interesting results. For example the peak memory consumption to read a manifest on a large repository is reduced from 600MB to 250MB (200MB without maxdeltachainspan). However, the slicing itself and the multiple reads can have an negative impact on performance. This is why the new feature is hidden behind an experimental flag. Future changesets will add various parameters to control the slicing heuristics. We hope to experiment a wide variety of repositories during 4.4 and hopefully turn the feature on by default in 4.5. As a first try, the algorithm itself is prone to deep changes. However, we wish to define APIs and have a baseline to work on.
Mon, 09 Oct 2017 15:13:41 +0200 revlog: ignore empty trailing chunks when reading segments
Paul Morelle <paul.morelle@octobus.net> [Mon, 09 Oct 2017 15:13:41 +0200] rev 34823
revlog: ignore empty trailing chunks when reading segments When a merge commit creates an empty diff in the revlog, its offset may still be quite far from the end of the previous chunk. Skipping these empty chunks may reduce read size significantly. In most cases, there is no gain, and in some cases, little gain. On my clone of pypy, `hg manifest` reads 65% less bytes (96140 i/o 275943) for revision 4260 by ignoring the only empty trailing diff. For revision 2229, 35% (34557 i/o 53435) Sadly, this is difficult to reproduce, as hg clone can make its own different structure every time.
Wed, 20 Sep 2017 19:17:37 +0200 phase: isolate logic to update remote phrase through bundle2 pushkey
Boris Feld <boris.feld@octobus.net> [Wed, 20 Sep 2017 19:17:37 +0200] rev 34822
phase: isolate logic to update remote phrase through bundle2 pushkey Move the logic to build bundle2 pushkey part into its dedicated function. It will help to keep the logic clear when adding support for sending phases change using 'phase-heads' part.
Wed, 11 Oct 2017 07:40:00 +0200 phase: generate a push-race detection part on push
Boris Feld <boris.feld@octobus.net> [Wed, 11 Oct 2017 07:40:00 +0200] rev 34821
phase: generate a push-race detection part on push We are about to switch phase pushing from using pushkey to using a the new dedicated binary part. We introduce the push race detection on its own to help detect potential impact.
Wed, 11 Oct 2017 07:13:02 +0200 phase: introduce a new 'check:phases' part
Boris Feld <boris.feld@octobus.net> [Wed, 11 Oct 2017 07:13:02 +0200] rev 34820
phase: introduce a new 'check:phases' part This part checks if revisions are still in the same phase as when the bundle was generated. This is similar to what 'check:heads' or 'check:updated-heads' bundle2 part achieves for changesets. We needs seems before we can move away from pushkey usage from phase since pushkey has it own built-in push-race detection.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip