Sat, 17 Mar 2018 20:00:54 +0900 templateutil: move flatten() from templater
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Mar 2018 20:00:54 +0900] rev 37157
templateutil: move flatten() from templater It's the same kind of utility as stringify().
Sun, 01 Apr 2018 01:27:18 -0400 server: ensure the incoming request falls under the prefix value stable 4.5.3
Matt Harbison <matt_harbison@yahoo.com> [Sun, 01 Apr 2018 01:27:18 -0400] rev 37156
server: ensure the incoming request falls under the prefix value Prior to this, the first test asserted in wsgiref.validate.check_environ() saying PATH didn't start with '/', but the second test served up the repo. The assertion was just added in this cycle (though the value of PATH is still wrong without the assertion). Allowing access to the repo at any URL outside of the prefix is a long standing bug. This also affected hgwebdir, at least when used via --subrepo. Paths are not being canonicalized, so accesses to things like 'foo/../bar' will get tossed out here, unless the prefix also matches.
Tue, 27 Mar 2018 11:01:13 -0400 stringutil: move person function from templatefilters
Connor Sheehan <sheehan@mozilla.com> [Tue, 27 Mar 2018 11:01:13 -0400] rev 37155
stringutil: move person function from templatefilters Move the person function from template filters to the stringutil module, so it can be reused in the mailmap template function. Differential Revision: https://phab.mercurial-scm.org/D2960
Thu, 22 Mar 2018 09:48:22 -0400 stringutil: add isauthorwellformed function
Connor Sheehan <sheehan@mozilla.com> [Thu, 22 Mar 2018 09:48:22 -0400] rev 37154
stringutil: add isauthorwellformed function The regular expression for this function formerly lived at https://hg.mozilla.org/hgcustom/version-control-tools/file/tip/hghooks/mozhghooks/author_format.py#l13 Differential Revision: https://phab.mercurial-scm.org/D2959
Sat, 17 Mar 2018 02:37:46 -0400 test-lfs-test-server: add a testcase for `hg serve`
Matt Harbison <matt_harbison@yahoo.com> [Sat, 17 Mar 2018 02:37:46 -0400] rev 37153
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
Thu, 29 Mar 2018 09:23:39 -0700 push: use "repo['.']" instead of old form "repo['']"
Martin von Zweigbergk <martinvonz@google.com> [Thu, 29 Mar 2018 09:23:39 -0700] rev 37152
push: use "repo['.']" instead of old form "repo['']" Note that this does not conflict with the commit message of my previous patch: I found this after writing the previous patch (besides, I very easily forget things). Differential Revision: https://phab.mercurial-scm.org/D2965
Thu, 29 Mar 2018 09:34:17 -0700 context: change default changeid from old form '' to '.'
Martin von Zweigbergk <martinvonz@google.com> [Thu, 29 Mar 2018 09:34:17 -0700] rev 37151
context: change default changeid from old form '' to '.' I don't think I've seen repo[''] in the codebase at least in the last two years. Differential Revision: https://phab.mercurial-scm.org/D2964
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip