zstandard: pull in bug fixes from upstream 0.9.1 release (issue5884) This changeset contains the meaningful code changes from python-zstandard's 0.9.1 release. The main fix is to restore support for compiling with mingw.

templatefuncs: only render text portion of minirst.format() result When "keep" argument is provided, the function returns (text, pruned), where pruned is a list of sections from the original plain text that were pruned from the rendered result. Let's not output it together with the rendered HTML.

tests: demonstrate that hgweb renders "pruned" that minirst.format() returns Notice at the bottom of the help text there's "windows". It's a section that is in the original help text, but was pruned (because hgweb didn't ask for it).

rebase: avoid RevlogError when computing obsoletenotrebased (issue5907) The key to reproducing this seems to be missing an obsolete node that is not an ancestor of the destination.

rebase: prioritize indicating an interrupted rebase over update (issue5838) This should also cover the transplant extension, and any other non clearable states.

tests: demonstrate inconsistent messaging around interrupted rebases

tests: adapt test-check-pylint to run on Windows The line endings are explicitly converted because this was ending up with '\r (no-eol) (esc)' lines, in addition to the usual '\r (esc)' lines. I've seen the fakerc output on other recently installed systems though (10.13 and/or Fedora 26). Unfortunately, the output here uses '\\' on Windows, so glob away the whole path.

hghave: avoid a deadlock reading the child process's output The output of `pylint` is voluminous enough that it fills the buffer on Windows, and waited for the parent to read it out. But the parent was waiting on the child to exit. I'm not sure what the intent of setting `ret = -1` in the exception handler just above this was...

lfs: bypass wrapped functions when reposetup() hasn't been called (issue5902) There are only a handful of methods that access repo attributes that are applied in reposetup(). The `diff` test covers all of the commands that call scmutil.prefetchfiles(). Along the way, I saw that adding files and upgrading the repo format were also problems (also tested here). I don't think running `hg serve` through the commandserver is sane, but I conditionalized both the capabilities and the wsgirequest handler because it's trivially correct. It doesn't look like there has ever been a caller of candownload(), so there's no test for that path. The upload case isn't testable, because uploadblobs() bails if there are no pointers. The requirement should be added any time pointers are introduced, and that would force the extension to be loaded specifically for the repo. This covers `debuglfsupload`, the pre-push hook (which isn't set until the repo is promoted to LFS), and uploadblobsfromrevs(), which can be called by other extensions. I think readfromstore() and writetostore() are only reachable as a flag processor for revlog.REVIDX_EXTSTORED, and a requirement is added as soon as that is seen, so I don't think those are a problem.

help: correct signature of separate() template function Without the dots, it looked as if separate() would take a list of arguments.

hgweb: do not try to replace signal handlers while locking According to the issue 5889, mod_wsgi issues a warning on signal.signal() call, and we wouldn't want to see it in error log. The problem addressed by d77c3b023393 could potentially occur in web session, but that would be less likely than in user processes.

lock: add internal config to not replace signal handlers while locking signal.signal() is blocked in some WSGI environments, and a horrible warning is sent to the server log. So we need a way to disable it, and I think abusing ui.config is the simplest workaround.

merge with i18n

i18n-pt_BR: synchronized with 32a75a8a5b0f

i18n-ja: fix block indentation

i18n-ja: synchronized with 32a75a8a5b0f

httppeer: declare 'dbg' at the function level As we just saw in the previous changeset, having the variable defined into a branch creates bug. This is a cheap to move it at the function level.

httppeer: properly gate debug usage behind debug flag check The "dbg" local variable is only defined if the 'debugflag' is set to True. However, it was used indiscriminately later in the function. We hide its usage behind the 'debugflag' value to avoid raising a NameError.

push: continue without locking on lock failure other than EEXIST (issue5882) This code was added by 3f5e75c22585 "push: make locking of source optional (issue3684)", but EACCES isn't the only error that could be triggered by filesystem permission. I think catching LockUnavailable is more appropriate than testing errno value by caller.

bdiff: fix yet more fallout from xdiff long/int64 conversion (issue5885) "l" in Py_BuildValue's format string means long, so passing int64_t instead results in fireworks on 32bit architectures. Differential Revision: https://phab.mercurial-scm.org/D3538

revset: pass in lookup function to matchany() (issue5879) Silly mistake in f83cb91b052e.

test-hgweb: add test for foo-bar name lookup This is broken since f83cb91b052e "revset: pass in lookup function instead of repo (API)."

bundle2: mark the bundle2 part as advisory (issue5872) It blocks old clients to read bundle including this part. Differential Revision: https://phab.mercurial-scm.org/D3481

debugbundle: also display if a part is mandatory or advisory Most parts are mandatory but when introducing new parts, they should be advisory if included by default or old clients won't be able to process it. Differential Revision: https://phab.mercurial-scm.org/D3480

Added signature for changeset 6614cac550ae

Added tag 4.6 for changeset 6614cac550ae

filelog: don't crash on invalid copy metadata (issue5748) "copy" and "copyrev" are both supposed to appear next to each other. However, a user report demonstrated a crash that indicates that something in the wild is producing "copy" without "copyrev" (probably `hg convert`). While we should definitely fix the source of the bad metadata, the bad code causing the crash is already in the wild and who knows how many repositories are impacted. So let's be more defensive when accessing the file revision metadata.

httppeer: detect redirect to URL without query string (issue5860) 197d10e157ce subtly changed the HTTP peer's handling of HTTP redirects. Before that changeset, we instantiated an HTTP peer instance and performed the capabilities lookup with that instance. The old code had the following relevant properties: 1) The HTTP request layer would automatically follow HTTP redirects. 2) An encountered HTTP redirect would update a peer instance variable pointing to the repo URL. 3) The peer would automagically perform a "capabilities" command request if a caller requested capabilities but capabilities were not yet defined. The first HTTP request issued by a peer is for ?cmd=capabilities. If the server responds with an HTTP redirect to a ?cmd=capabilities URL, the HTTP request layer automatically followed it, retrieved a valid capabilities response, and the peer's base URL was updated automatically so subsequent requests used the proper URL. In other words, things "just worked." In the case where the server redirected to a URL without the ?cmd=capabilities query string, the HTTP request layer would follow the redirect and likely encounter HTML. The peer's base URL would be updated and the unexpected Content-Type would raise a RepoError. We would catch RepoError and immediately call between() (testing the case for pre 0.9.1 servers not supporting the "capabilities" command). e.g. try: inst._fetchcaps() except error.RepoError: inst.between([(nullid, nullid)]) between() would eventually call into _callstream(). And _callstream() made a call to self.capable('httpheader'). capable() would call self.capabilities(), which would see that no capabilities were set (because HTML was returned for that request) and call the "capabilities" command to fetch capabilities. Because the base URL had been updated from the redirect, this 2nd "capabilities" command would succeed and the client would immediately call "between," which would also succeed. The legacy handshake succeeded. Only because "capabilities" was successfully executed as a side effect did the peer recognize that it was talking to a modern server. In other words, this all appeared to work accidentally. After 197d10e157ce, we stopped calling the "capabilities" command on the peer instance. Instead, we made the request via a low-level opener, detected the redirect as part of response handling code, and passed the redirected URL into the constructed peer instance. For cases where the redirected URL included the query string, this "just worked." But for cases where the redirected URL stripped the query string, we threw RepoError and because we removed the "between" handshake fallback, we fell through to the "is a static HTTP repo" check and performed an HTTP request for .hg/requires. While 197d10e157ce was marked as backwards incompatible, the only intended backwards incompatible behavior was not performing the "between" fallback. It was not realized that the "between" command had the side-effect of recovering from an errant redirect that dropped the query string. This commit restores the previous behavior and allows clients to handle a redirect that drops the query string. In the case where the request is redirected and the query string is dropped, we raise a special case of RepoError. We then catch this special exception in the handshake code and perform another "capabilities" request against the redirected URL. If that works, all is well. Otherwise, we fall back to the "is a static HTTP repo" check. The new code is arguably better than before 197d10e157ce, as it is explicit about the expected behavior and we avoid performing a "between" request, saving a server round trip. Differential Revision: https://phab.mercurial-scm.org/D3433