Mercurial > hg
view tests/test-merge-commit.t @ 37153:f51c2780db3a
test-lfs-test-server: add a testcase for `hg serve`
I haven't figured out yet how to make the authentication checks work for a
specific list of users, so the 'web.allow-push' list is wildcarded. (It appears
that the client doesn't react to a 401 by sending authentication data, which may
be caused in part by not having all of the headers in httpbasicauthhandler's
http_error_auth_reqed(), compared to a run of test-http.t. But in any case, we
should probably have a separate set of tests for various authentication
scenarios. As it is, without the wildcard, no push access is granted.)
There are several deviations from the `lfs-test-server` case:
- `hg serve` emits a Server header. I think Gregory indicated that this isn't
easily suppressed.
- `hg serve` names the "basic" transfer handler in the Batch API response. Not
having to specify it was for backwards compatability, so this seems like the
right thing to do. (`lfs-test-server` doesn't name it, whether it was
explicitly requested by the client or not.)
- PUT status for a newly created file is 201, per RFC-2616 [1]. The Basic
Transfer API [2] shows an example upload transcript with a 200 response. It
doesn't make much sense to re-upload a file (unless it is corrupt) in an
example, but I wouldn't be surprised if some other implementations also
expect 200 because of this. But the RFC says MUST use 201 for creation.
- The Content-Type for the file transfers is "application/octet-stream", like
the sample transcript (though I don't see it explicitly called out in the
text elsewhere). Using "text/plain" seems clearly wrong.
- `lfs-test-server` isn't removing the action property and sending back an
error code like the spec calls out when a file is missing or corrupt. Doing
so on the `hg serve` side reveals a bug in our client code when handling the
response- it indicates the remote file is missing instead of corrupt around
line 452.
I'll probably glob over the Content-Length differences once this settles down.
Prior to the recent hgweb refactoring, the Batch API response was using chunked
encodings instead.
Back to the RFC, I have no idea if the python framework handles the "MUST NOT
ignore any Content-* (e.g. Content-Range) headers that it does not understand or
implement and MUST return a 501" for a PUT request.
[1] https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6
[2] https://github.com/git-lfs/git-lfs/blob/master/docs/api/basic-transfers.md#uploads
author | Matt Harbison <matt_harbison@yahoo.com> |
---|---|
date | Sat, 17 Mar 2018 02:37:46 -0400 |
parents | eb586ed5d8ce |
children | 009d0283de5f |
line wrap: on
line source
Check that renames are correctly saved by a commit after a merge Test with the merge on 3 having the rename on the local parent $ hg init a $ cd a $ echo line1 > foo $ hg add foo $ hg ci -m '0: add foo' $ echo line2 >> foo $ hg ci -m '1: change foo' $ hg up -C 0 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg mv foo bar $ rm bar $ echo line0 > bar $ echo line1 >> bar $ hg ci -m '2: mv foo bar; change bar' created new head $ hg merge 1 merging bar and foo to bar 0 files updated, 1 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) $ cat bar line0 line1 line2 $ hg ci -m '3: merge with local rename' $ hg debugindex bar rev offset length ..... linkrev nodeid p1 p2 (re) 0 0 77 ..... 2 d35118874825 000000000000 000000000000 (re) 1 77 76 ..... 3 5345f5ab8abd 000000000000 d35118874825 (re) $ hg debugrename bar bar renamed from foo:9e25c27b87571a1edee5ae4dddee5687746cc8e2 $ hg debugindex foo rev offset length ..... linkrev nodeid p1 p2 (re) 0 0 7 ..... 0 690b295714ae 000000000000 000000000000 (re) 1 7 13 ..... 1 9e25c27b8757 690b295714ae 000000000000 (re) Revert the content change from rev 2: $ hg up -C 2 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ rm bar $ echo line1 > bar $ hg ci -m '4: revert content change from rev 2' created new head $ hg log --template '{rev}:{node|short} {parents}\n' 4:2263c1be0967 2:0f2ff26688b9 3:0555950ead28 2:0f2ff26688b9 1:5cd961e4045d 2:0f2ff26688b9 0:2665aaee66e9 1:5cd961e4045d 0:2665aaee66e9 This should use bar@rev2 as the ancestor: $ hg --debug merge 3 searching for copies back to rev 1 resolving manifests branchmerge: True, force: False, partial: False ancestor: 0f2ff26688b9, local: 2263c1be0967+, remote: 0555950ead28 preserving bar for resolve of bar starting 4 threads for background file closing (?) bar: versions differ -> m (premerge) picked tool ':merge' for bar (binary False symlink False changedelete False) merging bar my bar@2263c1be0967+ other bar@0555950ead28 ancestor bar@0f2ff26688b9 premerge successful 0 files updated, 1 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) $ cat bar line1 line2 $ hg ci -m '5: merge' $ hg debugindex bar rev offset length ..... linkrev nodeid p1 p2 (re) 0 0 77 ..... 2 d35118874825 000000000000 000000000000 (re) 1 77 76 ..... 3 5345f5ab8abd 000000000000 d35118874825 (re) 2 153 7 ..... 4 ff4b45017382 d35118874825 000000000000 (re) 3 160 13 ..... 5 3701b4893544 ff4b45017382 5345f5ab8abd (re) Same thing, but with the merge on 3 having the rename on the remote parent: $ cd .. $ hg clone -U -r 1 -r 2 a b adding changesets adding manifests adding file changes added 3 changesets with 3 changes to 2 files (+1 heads) new changesets 2665aaee66e9:0f2ff26688b9 $ cd b $ hg up -C 1 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg merge 2 merging foo and bar to bar 0 files updated, 1 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) $ cat bar line0 line1 line2 $ hg ci -m '3: merge with remote rename' $ hg debugindex bar rev offset length ..... linkrev nodeid p1 p2 (re) 0 0 77 ..... 2 d35118874825 000000000000 000000000000 (re) 1 77 76 ..... 3 5345f5ab8abd 000000000000 d35118874825 (re) $ hg debugrename bar bar renamed from foo:9e25c27b87571a1edee5ae4dddee5687746cc8e2 $ hg debugindex foo rev offset length ..... linkrev nodeid p1 p2 (re) 0 0 7 ..... 0 690b295714ae 000000000000 000000000000 (re) 1 7 13 ..... 1 9e25c27b8757 690b295714ae 000000000000 (re) Revert the content change from rev 2: $ hg up -C 2 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ rm bar $ echo line1 > bar $ hg ci -m '4: revert content change from rev 2' created new head $ hg log --template '{rev}:{node|short} {parents}\n' 4:2263c1be0967 2:0f2ff26688b9 3:3ffa6b9e35f0 1:5cd961e4045d 2:0f2ff26688b9 2:0f2ff26688b9 0:2665aaee66e9 1:5cd961e4045d 0:2665aaee66e9 This should use bar@rev2 as the ancestor: $ hg --debug merge 3 searching for copies back to rev 1 resolving manifests branchmerge: True, force: False, partial: False ancestor: 0f2ff26688b9, local: 2263c1be0967+, remote: 3ffa6b9e35f0 preserving bar for resolve of bar starting 4 threads for background file closing (?) bar: versions differ -> m (premerge) picked tool ':merge' for bar (binary False symlink False changedelete False) merging bar my bar@2263c1be0967+ other bar@3ffa6b9e35f0 ancestor bar@0f2ff26688b9 premerge successful 0 files updated, 1 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) $ cat bar line1 line2 $ hg ci -m '5: merge' $ hg debugindex bar rev offset length ..... linkrev nodeid p1 p2 (re) 0 0 77 ..... 2 d35118874825 000000000000 000000000000 (re) 1 77 76 ..... 3 5345f5ab8abd 000000000000 d35118874825 (re) 2 153 7 ..... 4 ff4b45017382 d35118874825 000000000000 (re) 3 160 13 ..... 5 3701b4893544 ff4b45017382 5345f5ab8abd (re) $ cd ..