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 42200
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 42199
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 42198
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 42197
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.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 tip