Sun, 24 Feb 2019 19:56:51 +0100 test: don't trust delta bases from the bundle in test-sparse-revlog.t stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 24 Feb 2019 19:56:51 +0100] rev 41794
test: don't trust delta bases from the bundle in test-sparse-revlog.t The point of the test is to check the strategy sparse-revlog uses to pick delta base. If we trust the bases used in the bundle, we no longer fully test this logic. In order to force this computation we have to use the side effect of a legacy format configuration `format.generaldelta`. The lack of a more official way to do so will be fixed in a later changeset.
Sun, 24 Feb 2019 19:56:57 +0100 test: update test-sparse-revlog.t output stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 24 Feb 2019 19:56:57 +0100] rev 41793
test: update test-sparse-revlog.t output This test is skipped unless a large artefact is pre-build. It seems like nobody ran it in a while. Changeset 3764330f76a6 changed the expected output but nobody noticed. This changeset focus on the first and simpler step: putting the expected output back to what one would get by running this test. However this test changes highlight a couple of deeper issues: 1) Even if the revision content did not changed, a change in the delta contained in the bundle affected the delta stored in the final revlog, changing the test result. Since we are testing the delta computation strategy with sparse, we should not blindly reuse the delta-base from the bundled delta. 2) A change in the format of the repository used to generate the bundle changed the delta stored in the bundle. We should get a more stable output to avoid future instabilities of this test. 3) The test is it not run by CI or developer. We'll try to address all this issues in the coming changesets.
Wed, 20 Feb 2019 15:02:59 -0500 bundle2: don't send "shared" requirement when cloning from a share
mitchell plamann <mplamann@janestreet.com> [Wed, 20 Feb 2019 15:02:59 -0500] rev 41792
bundle2: don't send "shared" requirement when cloning from a share Differential Revision: https://phab.mercurial-scm.org/D5985
Wed, 20 Feb 2019 14:57:00 -0500 tests: demonstrate failure when cloning from a share via bundle2
mitchell plamann <mplamann@janestreet.com> [Wed, 20 Feb 2019 14:57:00 -0500] rev 41791
tests: demonstrate failure when cloning from a share via bundle2 Differential Revision: https://phab.mercurial-scm.org/D5984
Fri, 22 Feb 2019 00:54:06 +0530 mq: disable qrecord during histedit (issue5981)
Navaneeth Suresh <navaneeths1998@gmail.com> [Fri, 22 Feb 2019 00:54:06 +0530] rev 41790
mq: disable qrecord during histedit (issue5981) qrecord during histedit may lead to deadlock-like situations. qpop will throw an error on called during histedit even after qrecord-ing those changes. This patch makes qrecord to abort on histedit. Differential Revision: https://phab.mercurial-scm.org/D5997
Wed, 20 Feb 2019 21:57:39 -0800 committablectx: move status-related methods closer together
Martin von Zweigbergk <martinvonz@google.com> [Wed, 20 Feb 2019 21:57:39 -0800] rev 41789
committablectx: move status-related methods closer together The modified()/added()/removed()/deleted() clearly belong very close to status(). I separated them in committablectx by the new p[12]copies() methods. This brings the close again. Sorry about the churn. Differential Revision: https://phab.mercurial-scm.org/D5996
Thu, 21 Feb 2019 23:07:54 -0500 tests: add test for hg-test-mode emacs code
Augie Fackler <augie@google.com> [Thu, 21 Feb 2019 23:07:54 -0500] rev 41788
tests: add test for hg-test-mode emacs code This is just coverage for the compilation-mode support, but that was enough of a hassle that I wanted to have it covered somehow. Test methodology is _extremely_ cargo-culted from the test for compilation-mode in emacs, so I still have no idea what I'm doing. Differential Revision: https://phab.mercurial-scm.org/D6003
Thu, 21 Feb 2019 23:06:18 -0500 hghave: add check for GNU emacs
Augie Fackler <augie@google.com> [Thu, 21 Feb 2019 23:06:18 -0500] rev 41787
hghave: add check for GNU emacs Differential Revision: https://phab.mercurial-scm.org/D6002
Thu, 21 Feb 2019 20:12:39 -0500 contrib: also linkify tracebacks in compilation output when using hg-test-mode
Augie Fackler <augie@google.com> [Thu, 21 Feb 2019 20:12:39 -0500] rev 41786
contrib: also linkify tracebacks in compilation output when using hg-test-mode Differential Revision: https://phab.mercurial-scm.org/D6001
Thu, 21 Feb 2019 19:59:00 -0500 contrib: add compilation-mode linking for our test output
Augie Fackler <augie@google.com> [Thu, 21 Feb 2019 19:59:00 -0500] rev 41785
contrib: add compilation-mode linking for our test output These regular expressions will cause compilation-mode buffers in emacs to link to source when there are check-code errors in the output of a .t test. In the true tradition of this file, I also have no idea what I'm doing. Differential Revision: https://phab.mercurial-scm.org/D6000
Fri, 22 Feb 2019 03:52:10 +0530 diff: make sure we output stat even when --git is not passed (issue4037) (BC)
Pulkit Goyal <pulkit@yandex-team.ru> [Fri, 22 Feb 2019 03:52:10 +0530] rev 41784
diff: make sure we output stat even when --git is not passed (issue4037) (BC) Before this patch, `hg diff --stat` will give an empty output. It will not show the stat information. I debugged and found that the underlying code does not return the diff header and due to that, other code paths fails to parse that as a diff. I looked into why we don't return diff headers in quiet mode and found the behavior is from 8f8bb77d560e70bcc95577e4dfa877df18d876ab which does not have any mention about why it is done. We also show the diff headers in git, so I think it's fine showing diff header in normal diff in quiet mode. Differential Revision: https://phab.mercurial-scm.org/D6007
Sat, 23 Feb 2019 04:50:46 +0530 tests: add test to demonstrate issue4037
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 23 Feb 2019 04:50:46 +0530] rev 41783
tests: add test to demonstrate issue4037 `hg diff --stat -q --config diff.git=0` does not output anything whereas it should print the stat. This is a quiet old bug dating to 2013 and looking at code I think it exists it since 2005 or when --stat was introduced. The next patch will fix the bug. Differential Revision: https://phab.mercurial-scm.org/D6006
Fri, 18 Jan 2019 11:07:46 -0800 grep: reuse getrenamedfn() from scmutil
Martin von Zweigbergk <martinvonz@google.com> [Fri, 18 Jan 2019 11:07:46 -0800] rev 41782
grep: reuse getrenamedfn() from scmutil My motivation is to reduce uses of filectx.renamed(). Reusing scmutil.getrenamedfn() also means that we get some caching of copy information per file and revision. I don't think that matters for `hg grep` (I doubt it speeds up significantly, and I doubt it wastes significant memory), but I'm not sure. Differential Revision: https://phab.mercurial-scm.org/D6022
Thu, 21 Feb 2019 10:54:29 -0800 templatekw: move getrenamedfn() to scmutil (API)
Martin von Zweigbergk <martinvonz@google.com> [Thu, 21 Feb 2019 10:54:29 -0800] rev 41781
templatekw: move getrenamedfn() to scmutil (API) The function is already used by `hg log` (for following renames, not for templates), so it seems it does not belong in templatekw. Differential Revision: https://phab.mercurial-scm.org/D6021
Sat, 23 Feb 2019 09:32:07 -0800 mq: get copy source from context object instead of from filelog
Martin von Zweigbergk <martinvonz@google.com> [Sat, 23 Feb 2019 09:32:07 -0800] rev 41780
mq: get copy source from context object instead of from filelog This removes dependence on filelog.renamed(). Differential Revision: https://phab.mercurial-scm.org/D6020
Sat, 23 Feb 2019 09:30:49 -0800 mq: slightly modernize by using context object
Martin von Zweigbergk <martinvonz@google.com> [Sat, 23 Feb 2019 09:30:49 -0800] rev 41779
mq: slightly modernize by using context object Context objects have existed since mid-2006. Differential Revision: https://phab.mercurial-scm.org/D6019
Sat, 23 Feb 2019 09:15:36 -0800 absorb: migrate to new method for getting copy info
Martin von Zweigbergk <martinvonz@google.com> [Sat, 23 Feb 2019 09:15:36 -0800] rev 41778
absorb: migrate to new method for getting copy info Differential Revision: https://phab.mercurial-scm.org/D6018
Mon, 11 Feb 2019 15:28:04 -0800 fix: migrate to new method for getting copy info
Martin von Zweigbergk <martinvonz@google.com> [Mon, 11 Feb 2019 15:28:04 -0800] rev 41777
fix: migrate to new method for getting copy info Differential Revision: https://phab.mercurial-scm.org/D6017
Sun, 25 Mar 2018 22:07:35 -0700 memfilefromctx: migrate to new method for getting copy info
Martin von Zweigbergk <martinvonz@google.com> [Sun, 25 Mar 2018 22:07:35 -0700] rev 41776
memfilefromctx: migrate to new method for getting copy info Differential Revision: https://phab.mercurial-scm.org/D6016
Wed, 27 Dec 2017 22:32:27 -0800 largefiles: migrate to new method for getting copy info
Martin von Zweigbergk <martinvonz@google.com> [Wed, 27 Dec 2017 22:32:27 -0800] rev 41775
largefiles: migrate to new method for getting copy info Differential Revision: https://phab.mercurial-scm.org/D6015
Wed, 27 Dec 2017 22:31:24 -0800 commit: migrate to new method for getting copy info
Martin von Zweigbergk <martinvonz@google.com> [Wed, 27 Dec 2017 22:31:24 -0800] rev 41774
commit: migrate to new method for getting copy info Differential Revision: https://phab.mercurial-scm.org/D6014
Wed, 27 Dec 2017 22:31:00 -0800 tests: migrate to new method for getting copy info
Martin von Zweigbergk <martinvonz@google.com> [Wed, 27 Dec 2017 22:31:00 -0800] rev 41773
tests: migrate to new method for getting copy info Differential Revision: https://phab.mercurial-scm.org/D6013
Mon, 26 Mar 2018 10:41:42 -0700 templatekw: migrate to new method for getting copy info
Martin von Zweigbergk <martinvonz@google.com> [Mon, 26 Mar 2018 10:41:42 -0700] rev 41772
templatekw: migrate to new method for getting copy info Differential Revision: https://phab.mercurial-scm.org/D6012
Wed, 27 Dec 2017 22:27:05 -0800 convert: migrate to new method for getting copy source
Martin von Zweigbergk <martinvonz@google.com> [Wed, 27 Dec 2017 22:27:05 -0800] rev 41771
convert: migrate to new method for getting copy source Differential Revision: https://phab.mercurial-scm.org/D6011
Sun, 25 Mar 2018 21:30:31 -0700 context: move equivalent renamed() implementations to superclass
Martin von Zweigbergk <martinvonz@google.com> [Sun, 25 Mar 2018 21:30:31 -0700] rev 41770
context: move equivalent renamed() implementations to superclass Now that renamed() in workingfilectx and in overlayfilectx are written in terms of copysource(), they are functionally identical and can be reused. Differential Revision: https://phab.mercurial-scm.org/D6010
Sun, 25 Mar 2018 21:28:30 -0700 context: rewrite renamed() in terms of new copysource() where appropriate
Martin von Zweigbergk <martinvonz@google.com> [Sun, 25 Mar 2018 21:28:30 -0700] rev 41769
context: rewrite renamed() in terms of new copysource() where appropriate It's only the filectx for committed files that have the copy source's nodeid easily available; workingfilectx's and overlayfilectx's renamed() simply find the nodeid by looking in the changeset's p1's manifest. Differential Revision: https://phab.mercurial-scm.org/D6009
Sun, 25 Mar 2018 21:32:16 -0700 context: add specialized way of getting copy source file only
Martin von Zweigbergk <martinvonz@google.com> [Sun, 25 Mar 2018 21:32:16 -0700] rev 41768
context: add specialized way of getting copy source file only I'm working on support for storing copy metadata in the changeset instead of the filelog. I don't intend to include the file nodeid there, but most callers don't need that anyway. This patch introduces a method similar to ctx.renamed(), but the new method returns only the source filename, not the nodeid. Subsequent patches will move callers over to this new method. Differential Revision: https://phab.mercurial-scm.org/D6008
Thu, 21 Feb 2019 21:27:42 -0800 changegroup: move non-pruning of non-ellipsis manifests to _prunemanifests()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 21 Feb 2019 21:27:42 -0800] rev 41767
changegroup: move non-pruning of non-ellipsis manifests to _prunemanifests() Google has an extension that overrides _prunemanifests() and removes nodes that we fetch using another mechanism. That broke when _prunemanifests() no longer got called. It works again if we move the check for "not self._ellipses" inside _prunemanifests(). Differential Revision: https://phab.mercurial-scm.org/D6004
Thu, 21 Feb 2019 19:11:35 -0800 context: use includematcher when checking dir/file conflicts
Kyle Lippincott <spectral@google.com> [Thu, 21 Feb 2019 19:11:35 -0800] rev 41766
context: use includematcher when checking dir/file conflicts This is for performance; patternmatcher can't easily interpret its results to make visitchildrenset be the "optimal" set of paths to inspect, but includematcher can. Since there aren't any special patterns being used here, I believe that the two matchers are equivalent. Differential Revision: https://phab.mercurial-scm.org/D5999
Thu, 21 Feb 2019 19:11:28 -0800 tests: change the paths slightly in test-rebase-inmemory.t
Kyle Lippincott <spectral@google.com> [Thu, 21 Feb 2019 19:11:28 -0800] rev 41765
tests: change the paths slightly in test-rebase-inmemory.t c/c was a little difficult to understand (and verify that it was the *correct* 'c/' that was being talked about), and it's useful to have multiple directories to prove that we are able to detect this even if there's no files (just a subdirectory) in the immediate directory that's conflicting. Differential Revision: https://phab.mercurial-scm.org/D5998
Wed, 16 Jan 2019 16:19:26 +0100 rust-cpython: using rustext.dagop.headrevs in revlog
Georges Racinet <georges.racinet@octobus.net> [Wed, 16 Jan 2019 16:19:26 +0100] rev 41764
rust-cpython: using rustext.dagop.headrevs in revlog As with the previous oxidation series, revlog plays the role of the factory, either using its parents function, or passing the index. We include below results of revsetbenchmarks.py taken on the PyPy repository on those of contrib/all-revsets.tx that involve `heads()`. In most of the cases, this seems to be either neutral or an improvement. In the cases where it's actually a bit slower, we suspect that differences in `heads()` performance is actually burried in variance on the incoming revset (probably several orders of magnitude slower). The precheck for filtered revisions of parent changeset has a significative performance benefit, too. Result by revset ================ Revision: 0) 0c7b353ce100; rust-cpython: binding for headrevs() 1) Parent of this changeset; changelog: prefilter in headrevs() 2) This changeset revset #0: heads(commonancestors(last(head(), 2))) plain min max first last reverse rev..rst rev..ast sort sor..rst sor..ast 0) 0.001379 0.001361 0.001381 0.001410 0.001393 0.001372 0.001414 0.001387 0.001411 0.001429 0.001415 1) 0.001351 0.001373 0.001383 0.001392 0.001401 0.001385 0.001405 0.001406 0.001385 0.001424 0.001399 2) 0.001365 0.001362 0.001375 0.001393 0.001370 0.001365 0.001413 0.001386 0.001377 0.001415 0.001411 revset #1: heads(commonancestors(head())) plain min max first last reverse rev..rst rev..ast sort sor..rst sor..ast 0) 0.047578 0.048578 0.047764 0.048065 0.047289 0.047305 0.047729 0.047370 0.047611 0.048005 0.047755 1) 0.048072 0.047471 0.048351 0.048193 0.048380 0.047968 0.047683 0.047355 0.048587 0.047044 0.048299 2) 0.047124 0.046699 0.046896 0.047250 0.046920 0.047379 0.046855 0.047753 0.047289 0.047219 0.046991 revset #2: heads(all()) plain min max first last reverse rev..rst rev..ast sort sor..rst sor..ast 0) 0.037654 0.037814 0.037149 0.037457 0.037609 0.037053 0.036825 0.037054 0.037739 0.036816 0.037604 1) 0.021845 58% 0.022172 58% 0.022148 59% 0.022059 58% 0.022261 59% 0.022246 60% 0.021691 58% 0.021967 59% 0.022156 58% 0.021820 59% 0.023141 61% 2) 0.014459 66% 0.014470 65% 0.014420 65% 0.014413 65% 0.014421 64% 0.014492 65% 0.014512 66% 0.014579 66% 0.014500 65% 0.014501 66% 0.014537 62% revset #3: heads(-10000:-1) plain min max first last reverse rev..rst rev..ast sort sor..rst sor..ast 0) 0.003696 0.003681 0.003719 0.003746 0.003725 0.003750 0.003692 0.003747 0.003712 0.003754 0.003763 1) 0.002131 57% 0.002142 58% 0.002147 57% 0.002203 58% 0.002143 57% 0.002208 58% 0.002158 58% 0.002182 58% 0.002169 58% 0.002209 58% 0.002201 58% 2) 0.001490 69% 0.001524 71% 0.001515 70% 0.001528 69% 0.001531 71% 0.001520 68% 0.001549 71% 0.001542 70% 0.001560 71% 0.001559 70% 0.001544 70% revset #4: (-5000:-1000) and heads(-10000:-1) plain min max first last reverse rev..rst rev..ast sort sor..rst sor..ast 0) 0.003832 0.003816 0.003747 0.003814 0.003749 0.003894 0.003784 0.003796 0.003915 0.003829 0.003795 1) 0.002282 59% 0.002208 57% 0.002220 59% 0.002240 58% 0.002210 58% 0.002276 58% 0.002250 59% 0.002250 59% 0.002311 59% 0.002230 58% 0.002241 59% 2) 0.001658 72% 0.001662 75% 0.001568 70% 0.001599 71% 0.001588 71% 0.001696 74% 0.001615 71% 0.001593 70% 0.001710 73% 0.001622 72% 0.001616 72% revset #5: heads(matching(tip, "author")) plain min max first last reverse rev..rst rev..ast sort sor..rst sor..ast 0) 7.826449 7.563260 7.581034 7.688493 7.634001 7.777860 7.768228 8.026097 7.767422 7.565254 7.938643 1) 7.750766 7.562555 7.660426 7.574089 7.492220 7.438582 7.562015 7.530635 93% 7.636343 7.636712 7.645113 2) 7.617941 7.519601 7.584922 7.507653 7.547440 7.524436 7.575291 7.883991 7.792142 7.709622 7.868595 revset #6: heads(matching(tip, "author")) and -10000:-1 plain min max first last reverse rev..rst rev..ast sort sor..rst sor..ast 0) 7.744489 7.728684 7.734065 7.928513 7.875949 7.883727 7.815492 7.791335 7.784793 7.761218 7.815731 1) 7.808956 7.480446 7.618759 7.920270 7.676343 7.803613 7.770210 7.713100 7.584420 7.767335 7.825140 2) 7.519987 7.938748 106% 7.805328 7.694162 7.750129 7.714229 7.603825 7.580734 7.555291 7.524207 7.504580 revset #7: (-10000:-1) and heads(matching(tip, "author")) plain min max first last reverse rev..rst rev..ast sort sor..rst sor..ast 0) 7.909321 7.694357 7.666021 7.538686 7.771821 7.876217 7.852103 7.812727 7.545919 7.788860 7.764585 1) 7.749232 7.683715 7.968393 7.895257 7.764160 8.314884 105% 7.921697 7.882613 7.867209 7.684707 7.544501 2) 7.824903 7.784605 7.727846 7.566613 7.581994 7.539205 90% 7.555316 7.535572 7.581786 7.901795 7.662832
Wed, 20 Feb 2019 11:49:06 +0100 changelog: prefilter in headrevs()
Georges Racinet <georges.racinet@octobus.net> [Wed, 20 Feb 2019 11:49:06 +0100] rev 41763
changelog: prefilter in headrevs() In case where headrevs() is called on some revisions, we perform the check that aren't filtered in advance, and switch revlog to use its unchecked form. This allows to work with alternative implementations that don't have knowledge of the filtering system, such as the Rust one.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -32 +32 +50 +100 +300 +1000 +3000 +10000 tip