Mercurial > hg
view tests/test-issue522.t @ 36534:5faeabb07cf5
debugcommands: support for triggering push protocol
The mechanism for pushing to a remote is a bit more complicated
than other commands. On SSH, we wait for a positive reply from
the server before we start sending the bundle payload.
This commit adds a mechanism to the "command" action in
`hg debugwireproto` to trigger the "push protocol" and to
specify a file whose contents should be submitted as the command
payload.
With this new feature, we implement a handful of tests for the
"unbundle" command. We try to cover various server failures and
hook/output scenarios so protocol behavior is as comprehensively
tested as possible. Even with so much test output, we only cover
bundle1 with Python hooks. There's still a lot of test coverage
that needs to be implemented. But this is certainly a good start.
Because there are so many new tests, we split these tests into their
own test file.
In order to make output deterministic, we need to disable the
doublepipe primitive. We add an option to `hg debugwireproto`
to do that. Because something in the bowels of the peer does a
read of stderr, we still capture read I/O from stderr. So there
is test coverage of what the server emits.
The tests around I/O capture some wonkiness. For example,
interleaved ui.write() and ui.write_err() calls are emitted in
order. However, (presumably due to buffering), print() to
sys.stdout and sys.stderr aren't in order.
We currently only test bundle1 because bundle2 is substantially
harder to test because it is more complicated (the server responds
with a stream containing a bundle2 instead of a frame).
Differential Revision: https://phab.mercurial-scm.org/D2471
author | Gregory Szorc <gregory.szorc@gmail.com> |
---|---|
date | Mon, 26 Feb 2018 18:01:13 -0800 |
parents | 2fc86d92c4a9 |
children | 009d0283de5f |
line wrap: on
line source
https://bz.mercurial-scm.org/522 In the merge below, the file "foo" has the same contents in both parents, but if we look at the file-level history, we'll notice that the version in p1 is an ancestor of the version in p2. This test makes sure that we'll use the version from p2 in the manifest of the merge revision. $ hg init $ echo foo > foo $ hg ci -qAm 'add foo' $ echo bar >> foo $ hg ci -m 'change foo' $ hg backout -r tip -m 'backout changed foo' reverting foo changeset 2:4d9e78aaceee backs out changeset 1:b515023e500e $ hg up -C 0 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ touch bar $ hg ci -qAm 'add bar' $ hg merge --debug searching for copies back to rev 1 unmatched files in local: bar resolving manifests branchmerge: True, force: False, partial: False ancestor: bbd179dfa0a7, local: 71766447bdbb+, remote: 4d9e78aaceee foo: remote is newer -> g getting foo 1 files updated, 0 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) $ hg debugstate | grep foo m 0 -2 unset foo $ hg st -A foo M foo $ hg ci -m 'merge' $ hg manifest --debug | grep foo c6fc755d7e68f49f880599da29f15add41f42f5a 644 foo $ hg debugindex foo rev offset length ..... linkrev nodeid p1 p2 (re) 0 0 5 ..... 0 2ed2a3912a0b 000000000000 000000000000 (re) 1 5 9 ..... 1 6f4310b00b9a 2ed2a3912a0b 000000000000 (re) 2 14 5 ..... 2 c6fc755d7e68 6f4310b00b9a 000000000000 (re)