view tests/test-dirstate-backup.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

Set up

  $ hg init repo
  $ cd repo

Try to import an empty patch

  $ hg import --no-commit - <<EOF
  > EOF
  applying patch from stdin
  abort: stdin: no diffs found
  [255]

No dirstate backups are left behind

  $ ls .hg/dirstate* | sort
  .hg/dirstate