Sun, 01 Apr 2018 23:12:37 +0900 hgweb: lift {sessionvars} to a wrapped type
Yuya Nishihara <yuya@tcha.org> [Sun, 01 Apr 2018 23:12:37 +0900] rev 37696
hgweb: lift {sessionvars} to a wrapped type Since a sessionvars object is updated in-place, we can't simply wrap it by mappinglist.
Sun, 01 Apr 2018 23:03:58 +0900 hgweb: make sessionvars class less dense
Yuya Nishihara <yuya@tcha.org> [Sun, 01 Apr 2018 23:03:58 +0900] rev 37695
hgweb: make sessionvars class less dense
Sun, 01 Apr 2018 23:03:02 +0900 hgweb: prefix private variables of sessionvars with '_'
Yuya Nishihara <yuya@tcha.org> [Sun, 01 Apr 2018 23:03:02 +0900] rev 37694
hgweb: prefix private variables of sessionvars with '_'
Fri, 13 Apr 2018 16:32:33 -0400 lfs: update the HTTP status codes in error cases
Matt Harbison <matt_harbison@yahoo.com> [Fri, 13 Apr 2018 16:32:33 -0400] rev 37693
lfs: update the HTTP status codes in error cases I'm not bothering with validating PUT requests (for now), because the spec doesn't explicitly call out a Content-Type (though the example transcript does use the sensible 'application/octet-stream').
Sun, 25 Feb 2018 14:07:13 -0500 lfs: gracefully handle aborts on the server when corrupt blobs are detected
Matt Harbison <matt_harbison@yahoo.com> [Sun, 25 Feb 2018 14:07:13 -0500] rev 37692
lfs: gracefully handle aborts on the server when corrupt blobs are detected The aborts weren't killing the server, but this seems cleaner. I'm not sure if it matters to handle the remaining IOError in the test like this, for consistency. The error code still feels wrong (especially if the client is trying to download a corrupt blob) but I don't see anything better in the RFCs, and this is already used elsewhere because the Batch API spec specifically mentioned this as a "Validation Error".
Fri, 13 Apr 2018 14:16:30 -0400 lfs: fix the inferred remote store path when using a --prefix
Matt Harbison <matt_harbison@yahoo.com> [Fri, 13 Apr 2018 14:16:30 -0400] rev 37691
lfs: fix the inferred remote store path when using a --prefix This wasn't appending the '.git/info/lfs' path in this case.
Fri, 13 Apr 2018 12:39:54 -0400 lfs: log information about Internal Server Errors reported in the Batch API
Matt Harbison <matt_harbison@yahoo.com> [Fri, 13 Apr 2018 12:39:54 -0400] rev 37690
lfs: log information about Internal Server Errors reported in the Batch API Reporting a 500 and then not leaving any traces on the server seems like a receipe for frustration. There's similar log writing in hgweb.server.do_POST(). That doesn't write directly to the wsgi.errors object, so it doesn't seem worth trying to refactor. It does seem like earlier stack frames are missing for some reason.
Sat, 07 Apr 2018 12:48:21 -0400 test-lfs: add tests to force server error path coverage
Matt Harbison <matt_harbison@yahoo.com> [Sat, 07 Apr 2018 12:48:21 -0400] rev 37689
test-lfs: add tests to force server error path coverage The tests are somewhat fragile in that the extension that forces the errors is counting how many times some of the functions are being called, so it depends heavily on the content of the repo. Maybe we can do something clever like load an extension on the client, and have it send over instructions in the HTTP header how to fail. (I'm trying to avoid killing and restarting the server, because Windows seems to have issues with doing that a lot.) But I'd rather fix issues than polish tests before the freeze.
Sat, 14 Apr 2018 10:43:19 -0400 keepalive: add ** overlooked in 83250442dc81
Augie Fackler <augie@google.com> [Sat, 14 Apr 2018 10:43:19 -0400] rev 37688
keepalive: add ** overlooked in 83250442dc81 Caught by Yuya in D3326. Differential Revision: https://phab.mercurial-scm.org/D3372
Sat, 14 Apr 2018 17:27:32 +0900 test-check-commit: don't run hg per commit
Yuya Nishihara <yuya@tcha.org> [Sat, 14 Apr 2018 17:27:32 +0900] rev 37687
test-check-commit: don't run hg per commit We aren't stress testing CPU. $ time ./run-tests.py -l test-check-commit.t --timeout 600 (orig) 162.59s user 17.98s system 101% cpu 2:58.55 total (new) 5.85s user 0.99s system 98% cpu 6.939 total
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip