Matt Harbison <matt_harbison@yahoo.com> [Mon, 28 Jan 2019 21:35:06 -0500] rev 41440
lfs: explicitly add the Content-Length header when uploading blobs, for py3
This was the reason for test-lfs-test-server.t#git-server complaining about an
"invalid byte in chunk length". For some reason if this isn't explicitly added,
py3.7.1 is adding `transfer-encoding: chunked` as well as `Content-length: x`.
Wireshark flagged this as malformed. However, if this is set, it doesn't bother
with `transfer-encoding`.
Before this patch with py3:
PUT /objects/31cf46fbc4ecd458a0943c5b4881f1f5a6dd36c53d6167d5b69ac45149b38e5b HTTP/1.1
Accept-Encoding: identity
Content-length: 12
accept: application/vnd.git-lfs
content-type: application/octet-stream
host: localhost:20062
transfer-encoding: chunked
user-agent: git-lfs/2.3.4 (Mercurial 4.9rc0+149-7eb7637e34bf)
Before this patch with py27:
PUT /objects/31cf46fbc4ecd458a0943c5b4881f1f5a6dd36c53d6167d5b69ac45149b38e5b HTTP/1.1
Accept-Encoding: identity
accept: application/vnd.git-lfs
content-type: application/octet-stream
content-length: 12
host: localhost:20062
user-agent: git-lfs/2.3.4 (Mercurial 4.9rc0+149-7eb7637e34bf+20190128)
With this patch and py3, the content is the same as the py27 example. RFC2616
says to ignore `Content-Length` if `Transfer-Encoding` is present, so maybe
there's nothing to do in the hg-server side (though I'm not sure which it is
using if presented both).
Maybe chunked encoding is better to do? If someone knows how to suppress the
`Content-Length`, we can try that instead.
Boris Feld <boris.feld@octobus.net> [Mon, 28 Jan 2019 03:20:31 -0500] rev 41439
perf: support looking up multiple revisions
The nodemap code has optimisations around the number of lookup we actually made.
As a result, being able to specify multiple revisions to look up is important
when measuring performances. One can now specify full revspecs with the --rev
arguments.
Boris Feld <boris.feld@octobus.net> [Fri, 25 Jan 2019 18:43:48 -0500] rev 41438
perf: add a no-lookup variant to perfindex
It is useful to check how long it takes to create a index object without doing
anything with it. We add a new flag dedicated to that.
Boris Feld <boris.feld@octobus.net> [Mon, 28 Jan 2019 04:47:40 -0500] rev 41437
perf: add some documentation to perfindex
It seems useful to document how the arguments can affect the benchmark.
Boris Feld <boris.feld@octobus.net> [Fri, 25 Jan 2019 14:53:19 -0500] rev 41436
perf: move cache clearing in the `setup` step of `perfheads`
The cache clearing is pretty fast, but this seems more "correct".
Boris Feld <boris.feld@octobus.net> [Fri, 25 Jan 2019 18:22:02 -0500] rev 41435
revlog: document cext oddities in terms of object/caches
This clarify why we just call clearcaches on a single object.
Boris Feld <boris.feld@octobus.net> [Fri, 25 Jan 2019 14:52:31 -0500] rev 41434
perf: document perfheads
Matt Harbison <matt_harbison@yahoo.com> [Sun, 27 Jan 2019 22:32:09 -0500] rev 41433
py3: stabilize the output of lfs commandserver tests
The print() statements were being output at the very end, so write to the same
stdout sink as runcommand, and explicitly flush.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 27 Jan 2019 20:58:18 -0500] rev 41432
py3: conditionalize some LFS test output
I'm not sure why the one stackframe is py2 only, but that seems harmless. The
remaining failure is LfsCorruptionError printing the fully qualified name, as
well as b'' around its message.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 27 Jan 2019 20:50:52 -0500] rev 41431
lfs: strip the response headers from the Batch API before printing
For reasons unknown, py3 is adding an extra '\n' before the headers print out.
This makes the output the same as py2.