test: use bundle2 in test-http Now that we have a bundle1 version of this test, we can move the original to bundle2. This lets us handle the ouput change from using the bundle2 protocol earlier.

test: copy test-http.t to test-http-bundle1.t We want to keep both code paths tested. The test is a bit too extensive to simply introduce dual testing in it so we make a copy for each protocol version.

test: use bundle2 in test-ssh Now that we have a bundle1 version of this test, we can move the main version to bundle2. This lets us handle the ouput change from using the bundle2 protocol earlier.

test: copy test-ssh.t to test-ssh-bundle1.t We want to keep both code paths tested. The test is a bit too extensive to simply introduce dual testing in it so we make a copy for each protocol version.

test: lock test-unbundlehash to bundle1 usage It is testing a bundle1 specific behavior. Bundle2 has its own way there. See inline comment for details.

test: use bundle2 in test-acl This test makes extensive use of --debug so moving to bundle2 based exchange has a massive impact. We do it early to reduce the noise create by a future usage of bundle2 as the default protocol.

test: use both bundle formats in test-pull-http It is valuable to have both formats tested.

test: use bundle2 in test-http-proxy The proxy test does not care about what protocol is used, but the new protocol implies different traffic (and therefore different log output). We switch it to bundle2 early to minimise the noise of using bundle2 for exchange by default.

tests: use bundle2 for test-hook Using bundle2 has an effect on which hooks are run when. We turn it on for test-hooks early to reduce the noise of switching the default exchange to bundle2.

pull: only prefetch bookmarks when using bundle1 All bundle2 servers now support the 'listkeys' part(1), so we'll always be able to fetch bookmarks data at the same time as the changeset. This should be enough to avoid the one race condition that this bookmark prefetching is trying to work around. It even allows future server to make sure everything is generated from the same "transaction" if they become capable of such. The current code was already overwriting the prefetched value with the one in bundle2 anyway. Note that this is not preventing all race conditions in related to bookmark in 'hg pull' it makes nothing better and nothing worse. Reducing the number of listkeys calls will reduce the latency on pull. The pre-fetch is also moved into a discovery step because it seems to belong there. (1) Because all servers not speaking 'pushkey' parts are compatible with the 'HG2X' protocol only.