runtest: extract the logic that update timeout for slow tests We want to use the "slow" test logic not only for "#require" clauses but also in "#if" clauses. For this to be useful we need the logic to bump the timeout in at least two spots. The first step it to factor it out.

tests: increase timeout for slow test Test case `test-sparse-revlog.t` need some artifact (a bundle) build before it can run. The artifact is expensive to build, but can be reused from one run to the other. We are about to update that test to make the artifact building automatic if `--allow-slow-tests` is passed. However, we need a bump the timeout a bit to make sure the artifact building as time to finish. We could maybe teach run-tests.py how to directly handle such artifacts. However since there is only one of them for now, this seems premature. There are also some room to speed up the bundle creation for test-sparse-revlog.t

merge with stable

rewriting: add an option for rewrite commands to use the archived phase Using the archived phase for cleanup provide the same effect than stripping, but in a faster, append-only way. We keep the feature experimental for now until it gets a bit more testing.

strip: introduce a soft strip option This is the first user-accessible way to use the archived phase introduced in 4.8. This implements a feature discussed during the Stockholm sprint, using the archived phase for hiding changesets. The archived phase behaves exactly as stripping: changesets are no longer visible, but pulling/unbundling them will make then reappear. The only notable difference is that unlike hard stripping, soft stripping does not affect obsmarkers. The next changeset will make use of the archived phase for history rewriting command. However, having a way to manually trigger the feature first seems a necessary step before exposing users to this phase; there is a way to un-archived changesets (unbundling), so there must be a way to archive them again. Adding a flag to strip is a good way to provide access to the feature without taking a too big risk on the final UI we want. The flag is experimental so it won't be exposed by default. Using the archived phase is faster and less traumatic for the repository than actually stripping changesets.

branchcache: move loading of branch names and nodes into it's own function This will help me in implementing lazy loading of the branchcache in upcoming patches. Differential Revision: https://phab.mercurial-scm.org/D6023

rebase: add missing dashes in help text

test: stabilize bundle generation for test-sparse-revlog.t To reduce the instability in the bundle binary content, we force it to contains delta against p1 in all cases. In the previous changeset, we already stabilized the processing of the bundle. So we don't see any output change in the test itself.

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.

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.