Mon, 22 Apr 2019 17:46:01 +0100 phabricator: use templatefilters.json in writediffproperties
Ian Moody <moz-ian@perix.co.uk> [Mon, 22 Apr 2019 17:46:01 +0100] rev 42188
phabricator: use templatefilters.json in writediffproperties Instead of json.dumps, since it makes the code simpler and more readable. This would have been the better option for 8fd19a7b4ed6 but I wasn't aware of it at the time. Differential Revision: https://phab.mercurial-scm.org/D6295
Sun, 21 Apr 2019 09:34:16 -0700 commands: use byteskwargs() in verify()
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 21 Apr 2019 09:34:16 -0700] rev 42187
commands: use byteskwargs() in verify() Otherwise Python 3 complains about the missing key. Differential Revision: https://phab.mercurial-scm.org/D6294
Sun, 21 Apr 2019 09:29:55 -0700 match: use raw strings to avoid illegal baskslash escape
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 21 Apr 2019 09:29:55 -0700] rev 42186
match: use raw strings to avoid illegal baskslash escape Python 3.8 was complaining about the invalid escape sequences. Let's use raw strings to avoid the warning and double baskslashes. Differential Revision: https://phab.mercurial-scm.org/D6293
Sat, 20 Apr 2019 00:48:16 +0300 revbranchcache: use context manager in _writerevs() to write to file
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 20 Apr 2019 00:48:16 +0300] rev 42185
revbranchcache: use context manager in _writerevs() to write to file The other _writenames() is a bit complicated to use context manager. Differential Revision: https://phab.mercurial-scm.org/D6292
Sat, 20 Apr 2019 00:44:18 +0300 revbranchcache: factor logic to write names and revs in separate functions
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 20 Apr 2019 00:44:18 +0300] rev 42184
revbranchcache: factor logic to write names and revs in separate functions Before this patch, the write function was so populated with upto 4 level of indentation, it was hard to understand what's going on. Differential Revision: https://phab.mercurial-scm.org/D6291
Thu, 18 Apr 2019 22:16:33 -0700 tests: make log style a little easier to read in test-copytrace-heuristics.t
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 22:16:33 -0700] rev 42183
tests: make log style a little easier to read in test-copytrace-heuristics.t Revision numbers are much shorter and easier to read (especially compared to the full nodeids that were used here), so I switched to that. That's also what almost all the commands used (e.g. `hg rebase -s . -d 1`). I updated the two instances that used nodeids. I also made some other little cleanups to the log templates. Differential Revision: https://phab.mercurial-scm.org/D6279
Thu, 18 Apr 2019 22:23:26 -0700 tests: avoid cryptic nodeids in tests/test-rename-merge1.t
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 22:23:26 -0700] rev 42182
tests: avoid cryptic nodeids in tests/test-rename-merge1.t These two nodeids had not been part of any output before, so one can't know which revision they refer to without adding something like `hg log` before them. It turned out that '.^' was equivalent for both of them, so that's what I replaced them with. Differential Revision: https://phab.mercurial-scm.org/D6280
Thu, 18 Apr 2019 22:08:58 -0700 tests: defines aliases for `hg log` calls in test-copytrace-heuristics.t
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 22:08:58 -0700] rev 42181
tests: defines aliases for `hg log` calls in test-copytrace-heuristics.t This also makes the test cases more consistent since a few had missed the ":" in "changeset:" that the others used. Differential Revision: https://phab.mercurial-scm.org/D6278
Thu, 14 Mar 2019 17:57:31 +0000 rust-discovery: implementing and exposing stats()
Georges Racinet <georges.racinet@octobus.net> [Thu, 14 Mar 2019 17:57:31 +0000] rev 42180
rust-discovery: implementing and exposing stats() This time, it's simple enough that we can do it in all layers in one shot. Differential Revision: https://phab.mercurial-scm.org/D6233
Wed, 20 Feb 2019 09:04:39 +0100 rust-discovery: cpython bindings for the core logic
Georges Racinet <georges.racinet@octobus.net> [Wed, 20 Feb 2019 09:04:39 +0100] rev 42179
rust-discovery: cpython bindings for the core logic As previously done with the ancestors submodule, testing for the bindings is provided from Python on a trivial case. Differential Revision: https://phab.mercurial-scm.org/D6232
Tue, 19 Feb 2019 23:42:31 +0100 rust-discovery: starting core implementation
Georges Racinet <georges.racinet@octobus.net> [Tue, 19 Feb 2019 23:42:31 +0100] rev 42178
rust-discovery: starting core implementation Once exposed to the Python side, this core object will avoid costly roundtrips with potentially big sets of revisions. This changeset implements the core logic of the object only, i.e., manipulation of the missing, common and undefined set-like revision attributes. Differential Revision: https://phab.mercurial-scm.org/D6231
Wed, 20 Feb 2019 18:33:53 +0100 rust-dagops: roots
Georges Racinet <georges.racinet@octobus.net> [Wed, 20 Feb 2019 18:33:53 +0100] rev 42177
rust-dagops: roots Unsuprisingly, the algorithm is much easier than for heads, provided we work on a set in the first place. To improve the signature, a trait for set-likes object would be useful, but that's not an immediate concern. Differential Revision: https://phab.mercurial-scm.org/D6230
Tue, 19 Feb 2019 23:41:57 +0100 rust-dagops: range of revisions
Georges Racinet <georges.racinet@octobus.net> [Tue, 19 Feb 2019 23:41:57 +0100] rev 42176
rust-dagops: range of revisions This is a Rust implementation for what reachableroots2() does if includepath is True. The algorithmic details and performance notes are included in the documentation comment. Our main use case for now is a Rust counterpart of the partialdiscovery object, so we don't really need bindings yet. Differential Revision: https://phab.mercurial-scm.org/D6229
Sun, 21 Apr 2019 08:57:01 -0700 setup: tweak error message for Python 3 stable
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 21 Apr 2019 08:57:01 -0700] rev 42175
setup: tweak error message for Python 3 We now have beta support for Python 3. In my opinion, it isn't yet stable enough to allow `pip install Mercurial` to work with Python 3 out of the box: we don't want people accidentally using Mercurial with Python 3 just yet. But I do think we should be more friendly about informing people of their options. This commit tweaks the error message that users see when running setup.py with Python 3. We instruct them about the current level of Python 3 support, point them at the wiki for more info, and give them instructions on how to bypass the check. As part of this, I also changed which version value is printed, as we were printing a named tuple before.
Sun, 21 Apr 2019 07:21:08 -0700 setup: remove set and dict comprehensions stable
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 21 Apr 2019 07:21:08 -0700] rev 42174
setup: remove set and dict comprehensions Yuya observed in a recent review that it is worthwhile to keep setup.py parseable with Python 2.6 so a useful error message is seen when attempting to run with Python 2.6. This commit removes a set and dict comprehension so setup.py is parseable with Python 2.6.
Fri, 19 Apr 2019 23:13:28 +0300 branchcache: don't verify all nodes while writing stable
Pulkit Goyal <pulkit@yandex-team.ru> [Fri, 19 Apr 2019 23:13:28 +0300] rev 42173
branchcache: don't verify all nodes while writing nodes are verified either when they are added or used. In case of commits. we will load the whole branchmap, only verify nodes for the branch on which we are committing and then we write. However before this patch, writing the branchmap was validating all the nodes whereas it should not. This patch fixes that. Differential Revision: https://phab.mercurial-scm.org/D6290
Sat, 20 Apr 2019 07:29:07 -0700 setup: properly package distutils in py2exe virtualenv builds stable
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 20 Apr 2019 07:29:07 -0700] rev 42172
setup: properly package distutils in py2exe virtualenv builds Our in-repo py2exe packaging code uses virtualenvs for managing dependencies. An advantage of this is that packaging is more deterministic and reproducible. Without virtualenvs, we need to install packages in the system Python install. Packages installed by other consumers of the system Python could leak into the Mercurial package. A regression from this change was that py2exe packages contained the virtualenv's hacked distutils modules instead of the original distutils modules. (virtualenv installs a hacked distutils module because distutils uses relative path lookups that fail when running from a virtualenv.) This commit introduces a workaround so py2exe packaging uses the original distutils modules when running from a virtualenv. With this change, `import distutils` no longer fails from py2exe builds produced from a virtualenv. This fixes the regression. Furthermore, we now include all distutils modules. Before, py2exe's module finding would only find modules there were explicitly referenced in code. So, we now package a complete copy of distutils instead of a partial one. This is even better than before. # no-check-commit foo_bar function name
Wed, 17 Apr 2019 10:49:11 -0700 narrow: also warn when not deleting untracked or ignored files
Martin von Zweigbergk <martinvonz@google.com> [Wed, 17 Apr 2019 10:49:11 -0700] rev 42171
narrow: also warn when not deleting untracked or ignored files Differential Revision: https://phab.mercurial-scm.org/D6265
Wed, 17 Apr 2019 14:37:06 +0200 setdiscovery: fix a few typos
Joerg Sonnenberger <joerg@bec.de> [Wed, 17 Apr 2019 14:37:06 +0200] rev 42170
setdiscovery: fix a few typos Differential Revision: https://phab.mercurial-scm.org/D6263
Mon, 15 Apr 2019 14:09:18 -0700 copies: delete debug message about "unmatched files new in both"
Martin von Zweigbergk <martinvonz@google.com> [Mon, 15 Apr 2019 14:09:18 -0700] rev 42169
copies: delete debug message about "unmatched files new in both" Same reasoning as previous patch. Differential Revision: https://phab.mercurial-scm.org/D6251
Fri, 12 Apr 2019 21:41:51 -0700 copies: delete debug message about changes since common ancestor
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Apr 2019 21:41:51 -0700] rev 42168
copies: delete debug message about changes since common ancestor Same reasoning as previous patch. Differential Revision: https://phab.mercurial-scm.org/D6250
Thu, 11 Apr 2019 23:28:38 -0700 copies: delete debug message about search limit
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Apr 2019 23:28:38 -0700] rev 42167
copies: delete debug message about search limit I'm about to rewrite mergecopies() and this message will no longer be emitted then. Let's remove the message now to remove a distraction from that patch. Differential Revision: https://phab.mercurial-scm.org/D6249
Mon, 15 Apr 2019 22:58:10 -0700 copies: move early return for "no copies" case a little earlier
Martin von Zweigbergk <martinvonz@google.com> [Mon, 15 Apr 2019 22:58:10 -0700] rev 42166
copies: move early return for "no copies" case a little earlier We can return before the block that prints debug messages. That block will not be run anyway when there are no copies. Differential Revision: https://phab.mercurial-scm.org/D6248
Mon, 15 Apr 2019 16:46:41 -0700 copies: fix up "fullcopy" with missing entries from "diverge"
Martin von Zweigbergk <martinvonz@google.com> [Mon, 15 Apr 2019 16:46:41 -0700] rev 42165
copies: fix up "fullcopy" with missing entries from "diverge" Similar to the previous patch, but this doesn't even affect tests. It does affect tests if you change them to turn on debug logging. I'm fixing it here so reviewers of the later rewrite patch can hard-code debug logging to be on and more easily compare test results. Differential Revision: https://phab.mercurial-scm.org/D6247
Mon, 15 Apr 2019 16:41:43 -0700 copies: fix up "fullcopy" with missing entries from "copy"
Martin von Zweigbergk <martinvonz@google.com> [Mon, 15 Apr 2019 16:41:43 -0700] rev 42164
copies: fix up "fullcopy" with missing entries from "copy" This is just a workaround similar to the previous one. It will make it easier to follow later patches. Differential Revision: https://phab.mercurial-scm.org/D6246
Sun, 14 Apr 2019 00:46:25 -0700 merge: remove workaround for issue5020
Martin von Zweigbergk <martinvonz@google.com> [Sun, 14 Apr 2019 00:46:25 -0700] rev 42163
merge: remove workaround for issue5020 As I explained in the previous commit, I think the filtering added there is a better fix for the issue, so the workaround from 41f6af50c0d8 (merge: fix crash on criss cross merge with dir move and delete (issue5020), 2017-01-31) should no longer be needed. Differential Revision: https://phab.mercurial-scm.org/D6245
Fri, 12 Apr 2019 22:03:04 -0700 copies: don't include copies that are not in source in directory move
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Apr 2019 22:03:04 -0700] rev 42162
copies: don't include copies that are not in source in directory move I've been working on a rewrite of mergecopies(). I compared the output of the rewritten version with the current version. I noticed that between FIREFOX_NIGHTLY_59_END and FIREFOX_BETA_60_BASE in the mozilla-unified repo, there were many copies that the current version detected that the rewritten version did not. One example was js/src/gc/Iteration.h -> js/src/gc/PublicIterators.h. Then I realized that js/src/gc/Iteration.h doesn't even exist in FIREFOX_NIGHTLY_59_END. This patch adds a filtering step for the "fullcopy" dict. It turns out that that change also affects the test for issue5020 in test-merge-criss-cross.t. The 'dm' action no longer happens there. At first I thought that the test case change meant that this patch was broken, but I think it's actually correct tha the 'dm' action should not happen there. The result of the bid merge is still the same. I suspect this filtering is a better solution for the issue than 41f6af50c0d8 (merge: fix crash on criss cross merge with dir move and delete (issue5020), 2017-01-31). I also suspect that it was broken just a few months earlier by a005c33d0bd7 (mergecopies: add logic to process incomplete data, 2016-10-04). Note that bid merge had been enabled for a few years at that point, since 19903277f035 (merge: use bid merge by default (BC), 2014-10-01). This patch is still just a workaround. It will be cleaned up soon (with the rewrite of mergecopies()). But doing this in a separate patch makes later patches easier to understand and gives a place to explain why this is changing. Differential Revision: https://phab.mercurial-scm.org/D6244
Sat, 13 Apr 2019 00:24:17 -0700 tests: add test for issue5343 (grafting with copies)
Martin von Zweigbergk <martinvonz@google.com> [Sat, 13 Apr 2019 00:24:17 -0700] rev 42161
tests: add test for issue5343 (grafting with copies) It seems that issue5353 resulted in a lot of tests in test-graft.t, but the bug actually reported in that issue didn't get a test case. This patch adds one for the "move" and one for the "copy" version of it. I also added a "copy+modify" case, to show what should be a merge conflict. I didn't add one for the "backwards" version of it since the comment says that that was already covered by previous work. The tests added by this patch show the broken behavior (the bug is still open). I suspect the results returned from mergecopies() are not expressive enough to fix this issue: it has a dict for copies to merge with, but that can only give one more filename, but here we need two (one for the path on the remote side and one for the path in the merge base). I want to have it tested anyway since I'm about to refactor mergecopies(). Differential Revision: https://phab.mercurial-scm.org/D6242
Tue, 16 Apr 2019 13:12:21 -0400 chistedit: use context manager to set verbose ui
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Tue, 16 Apr 2019 13:12:21 -0400] rev 42160
chistedit: use context manager to set verbose ui I'm still not exactly sure why this is necessary -- perhaps setting it unconditionally would leak this setting in chg invocations. Regardless, this would have looked very out of place as compared to how this setting is done everywhere else, so at least for the sake of style, let's be consistent with the rest of the codebase.
Tue, 16 Apr 2019 17:26:38 +0200 setdiscovery: stop limiting the number of local head we initially send
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 Apr 2019 17:26:38 +0200] rev 42159
setdiscovery: stop limiting the number of local head we initially send In our testing this limitation provides now real gain and instead triggers pathological discovery timing for some repository with many heads. See inline documentation for details. Some timing below: Mozilla try repository, (~1M revs, ~35K heads), discovery between 2 clones with 100 head missing on each side before: ! wall 1.492111 comb 1.490000 user 1.450000 sys 0.040000 (best of 20) ! wall 1.813992 comb 1.820000 user 1.700000 sys 0.120000 (max of 20) ! wall 1.574326 comb 1.573500 user 1.522000 sys 0.051500 (avg of 20) ! wall 1.572583 comb 1.570000 user 1.520000 sys 0.050000 (median of 20) after: ! wall 1.147834 comb 1.150000 user 1.090000 sys 0.060000 (best of 20) ! wall 1.449144 comb 1.450000 user 1.330000 sys 0.120000 (max of 20) ! wall 1.204618 comb 1.202500 user 1.146500 sys 0.056000 (avg of 20) ! wall 1.194407 comb 1.190000 user 1.140000 sys 0.050000 (median of 20) pypy (~100 heads, 317 heads) discovery between clones with only 42 common heads before: ! wall 0.031653 comb 0.030000 user 0.030000 sys 0.000000 (best of 25) ! wall 0.055719 comb 0.050000 user 0.040000 sys 0.010000 (max of 25) ! wall 0.038939 comb 0.039600 user 0.038400 sys 0.001200 (avg of 25) ! wall 0.038660 comb 0.050000 user 0.040000 sys 0.010000 (median of 25) after: ! wall 0.018754 comb 0.020000 user 0.020000 sys 0.000000 (best of 49) ! wall 0.034505 comb 0.040000 user 0.030000 sys 0.010000 (max of 49) ! wall 0.019631 comb 0.019796 user 0.018367 sys 0.001429 (avg of 49) ! wall 0.019132 comb 0.020000 user 0.020000 sys 0.000000 (median of 49) Private repository (~1M revs, ~3K heads), discovery from a strip subset, about 100 changesets to be pulled. before: ! wall 1.837729 comb 1.840000 user 1.790000 sys 0.050000 (best of 20) ! wall 2.203468 comb 2.200000 user 2.100000 sys 0.100000 (max of 20) ! wall 2.049355 comb 2.048500 user 2.002500 sys 0.046000 (avg of 20) ! wall 2.035315 comb 2.040000 user 2.000000 sys 0.040000 (median of 20) after: ! wall 0.136598 comb 0.130000 user 0.110000 sys 0.020000 (best of 20) ! wall 0.330519 comb 0.330000 user 0.260000 sys 0.070000 (max of 20) ! wall 0.157254 comb 0.155500 user 0.123000 sys 0.032500 (avg of 20) ! wall 0.149870 comb 0.140000 user 0.110000 sys 0.030000 (median of 20) Same private repo, discovery between two clone with 500 different heads on each side: before: ! wall 2.372919 comb 2.370000 user 2.320000 sys 0.050000 (best of 20) ! wall 2.622422 comb 2.610000 user 2.510000 sys 0.100000 (max of 20) ! wall 2.450135 comb 2.450000 user 2.402000 sys 0.048000 (avg of 20) ! wall 2.443896 comb 2.450000 user 2.410000 sys 0.040000 (median of 20) after: ! wall 0.625497 comb 0.620000 user 0.570000 sys 0.050000 (best of 20) ! wall 0.834723 comb 0.820000 user 0.730000 sys 0.090000 (max of 20) ! wall 0.675725 comb 0.675500 user 0.628000 sys 0.047500 (avg of 20) ! wall 0.671614 comb 0.680000 user 0.640000 sys 0.040000 (median of 20)
Wed, 17 Apr 2019 17:56:30 +0200 peer: introduce a limitedarguments attributes
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 Apr 2019 17:56:30 +0200] rev 42158
peer: introduce a limitedarguments attributes When set to True, it signal that the peer cannot receive too larges arguments and that algorithm must adapt. This should only be True for http peer that does not support argument passed as "post". This will be useful to unlock better discovery performance in the next changesets. I am using a dedicated argument because this is not really a usual "capabilities" things. An alternative approach would be to adds a "large-arguments" to all peer, but the http peers. That seemed a bit too hacky to me.
Wed, 06 Mar 2019 15:06:53 +0100 verify: also check full manifest validity during verify runs
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2019 15:06:53 +0100] rev 42157
verify: also check full manifest validity during verify runs Before this changes, `hg verify` only checked if a manifest revision existed and referenced the proper files. However it never checked the manifest revision content itself. Mercurial is expecting manifest entries to be sorted and will crash otherwise. Since `hg verify` did not attempted a full restoration of manifest entry, it could ignore this kind of corruption. This new check significantly increases the cost of a `hg verify` run. This especially affects large repository not using `sparse-revlog`. For now, this is hidden behind the `--full` experimental flag.
Wed, 17 Apr 2019 01:11:09 +0200 verify: introduce an experimental --full flag
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 Apr 2019 01:11:09 +0200] rev 42156
verify: introduce an experimental --full flag The flag currently has no effect, see next changeset for details. We introduce the flag as experimental to keep the freedom of changing our mind on the final UI. Note: this patch highlight a small but in `hg help`. An option section is generated even if no option are visible.
Wed, 17 Apr 2019 01:12:21 +0200 verify: introduce a notion of "level"
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 Apr 2019 01:12:21 +0200] rev 42155
verify: introduce a notion of "level" Some checks are slower than others, to help the user to run the checks he needs, we are about to introduce new flag to select faster vs deeper runs. This put the scaffolding in place to do this.
Sat, 13 Apr 2019 23:18:56 -0700 tests: split out separate test for issue5020
Martin von Zweigbergk <martinvonz@google.com> [Sat, 13 Apr 2019 23:18:56 -0700] rev 42154
tests: split out separate test for issue5020 The test was added to the existing setup in 41f6af50c0d8 (merge: fix crash on criss cross merge with dir move and delete (issue5020), 2017-01-31). I'm about to make a change that affects that test and it's much easier to follow if the test case for issue5020 is a separate test case. The separate test case is based on what mpm provided in comment 12 on the issue. `hg diff -r 41f6af50c0d8^ tests/test-merge-criss-cross.t` after this patch is pretty small (besides the added test). It's probably easier for reviewers to look at that than to try to understand the diff itself (I don't understand it). Differential Revision: https://phab.mercurial-scm.org/D6243
Mon, 15 Apr 2019 18:04:54 -0700 tests: avoid a rename/delete conflict when updating in test-narrow-update.t
Martin von Zweigbergk <martinvonz@google.com> [Mon, 15 Apr 2019 18:04:54 -0700] rev 42153
tests: avoid a rename/delete conflict when updating in test-narrow-update.t After the upcoming rewrite of mergecopies(), this test would otherwise (accurately) start warning about "inside/f1 was deleted and renamed". Differential Revision: https://phab.mercurial-scm.org/D6254
Mon, 15 Apr 2019 15:28:41 -0700 tests: delete unused function in test-rename-merge2.t
Martin von Zweigbergk <martinvonz@google.com> [Mon, 15 Apr 2019 15:28:41 -0700] rev 42152
tests: delete unused function in test-rename-merge2.t Differential Revision: https://phab.mercurial-scm.org/D6253
Sun, 14 Apr 2019 13:46:40 -0700 tests: make merge conflicts explicit in `hg annotate` tests
Martin von Zweigbergk <martinvonz@google.com> [Sun, 14 Apr 2019 13:46:40 -0700] rev 42151
tests: make merge conflicts explicit in `hg annotate` tests We were using `true` as merge tool. I think it makes the test easier to understand if we make the conflicts explcit. It also papered over a conflict that shouldn't have been a conflict (just a bug in copy tracing). I've marked that "BROKEN". Differential Revision: https://phab.mercurial-scm.org/D6252
Thu, 18 Apr 2019 03:05:42 +0530 narrow: make warning about possibly dirty files respect ui.relative-paths
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 03:05:42 +0530] rev 42150
narrow: make warning about possibly dirty files respect ui.relative-paths Differential Revision: https://phab.mercurial-scm.org/D6264
Wed, 17 Apr 2019 14:10:02 -0400 merge: forgot to pull before release stable
Augie Fackler <augie@google.com> [Wed, 17 Apr 2019 14:10:02 -0400] rev 42149
merge: forgot to pull before release These two changes should be part of 5.0, but we are fine leaving them out of the RC.
Wed, 17 Apr 2019 13:56:10 -0400 Added signature for changeset 4a8d9ed86475 stable
Augie Fackler <raf@durin42.com> [Wed, 17 Apr 2019 13:56:10 -0400] rev 42148
Added signature for changeset 4a8d9ed86475
Wed, 17 Apr 2019 13:56:08 -0400 Added tag 5.0rc0 for changeset 4a8d9ed86475 stable
Augie Fackler <raf@durin42.com> [Wed, 17 Apr 2019 13:56:08 -0400] rev 42147
Added tag 5.0rc0 for changeset 4a8d9ed86475
Wed, 17 Apr 2019 13:41:18 -0400 merge: default into stable for release candidate stable 5.0rc0
Augie Fackler <augie@google.com> [Wed, 17 Apr 2019 13:41:18 -0400] rev 42146
merge: default into stable for release candidate
Tue, 16 Apr 2019 15:50:20 +0200 debugdiscovery: include the number of heads in all sets
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 Apr 2019 15:50:20 +0200] rev 42145
debugdiscovery: include the number of heads in all sets We already displayed information about heads of the common set that are either local or remote heads. We now also do so for heads of the common set that are both local and remote heads too. This is useful because various step in the set discovery algorithm have head specific optimizations.
Wed, 17 Apr 2019 00:37:00 +0200 recover: add a --[no-]verify flag
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 Apr 2019 00:37:00 +0200] rev 42144
recover: add a --[no-]verify flag For trivial cases, the cost of the verify run after `hg recover` is getting in the way. In addition for very large repositories, the cost is simply too high to be paid, making `hg recover` an unusable commands. We introduce a --verify flag, set by default. If is automatically associated with a --no-verify flag that one can use to skip the verify step. We might consider changing the default behavior in the future. However this is out of scope for this series.
Tue, 02 Apr 2019 19:48:31 +0200 bundle2: handle compression in _forwardchunks
Joerg Sonnenberger <joerg@bec.de> [Tue, 02 Apr 2019 19:48:31 +0200] rev 42143
bundle2: handle compression in _forwardchunks _forwardchunks is used to compensate for getbundle protocol deficits. Since it transparently decodes the payload, it also needs to remove the corresponding compression parameter in case the server decides to send one. This the wire protocol part of issue 5990. Differential Revision: https://phab.mercurial-scm.org/D6182
Wed, 27 Dec 2017 22:05:20 -0800 changelog: parse copy metadata if available in extras
Martin von Zweigbergk <martinvonz@google.com> [Wed, 27 Dec 2017 22:05:20 -0800] rev 42142
changelog: parse copy metadata if available in extras This lets read back the copy metadata we just started writing. There are still many places left to teach about getting the copy information from the changeset, but we have enough ({file_copies}, specifically) that we can add it now and have some test coverage of it. Differential Revision: https://phab.mercurial-scm.org/D6186
Wed, 27 Dec 2017 19:49:36 -0800 copies: add config option for writing copy metadata to file and/or changset
Martin von Zweigbergk <martinvonz@google.com> [Wed, 27 Dec 2017 19:49:36 -0800] rev 42141
copies: add config option for writing copy metadata to file and/or changset This introduces a config option that lets you choose to write copy metadata to the changeset extras instead of to filelog. There's also an option to write it to both places. I imagine that may possibly be useful when transitioning an existing repo. The copy metadata is stored as two fields in extras: one for copies since p1 and one for copies since p2. I may need to add more information later in order to make copy tracing faster. Specifically, I'm thinking out recording which files were added or removed so that copies._chaincopies() doesn't have to look at the manifest for that. But that would just be an optimization and that can be added once we know if it's necessary. I have also considered saving space by using replacing the destination file path by an index into the "files" list, but that can also be changed later (but before the feature is ready to release). Differential Revision: https://phab.mercurial-scm.org/D6183
(0) -30000 -10000 -3000 -1000 -300 -100 -48 +48 +100 +300 +1000 +3000 +10000 tip