tests/test-eol-tag.t

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

https://bz.mercurial-scm.org/2493

Testing tagging with the EOL extension

  $ cat >> $HGRCPATH <<EOF
  > [extensions]
  > eol =
  > 
  > [eol]
  > native = CRLF
  > EOF

setup repository

  $ hg init repo
  $ cd repo
  $ cat > .hgeol <<EOF
  > [patterns]
  > ** = native
  > EOF
  $ printf "first\r\nsecond\r\nthird\r\n" > a.txt
  $ hg commit --addremove -m 'checkin'
  adding .hgeol
  adding a.txt

Tag:

  $ hg tag 1.0

Rewrite .hgtags file as it would look on a new checkout:

  $ hg update -q null
  $ hg update -q

Touch .hgtags file again:

  $ hg tag 2.0

  $ cd ..