- May 05, 2018
-
-
Kevin Bullock authored
-
Kevin Bullock authored
-
- Dec 01, 2017
-
-
Gregory Szorc authored
"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.
-
- Apr 30, 2018
-
-
Gregory Szorc authored
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
-
- May 03, 2018
-
-
Yuya Nishihara authored
Follow up for the previous patch.
-
Gregory Szorc authored
This restores the styling that was accidentally removed by the previous change to these files. Differential Revision: https://phab.mercurial-scm.org/D3438
-
Gregory Szorc authored
The use of inline href="javascript:" undermines CSP policies that don't allow inline javascript. This commit changes the registering of the diffstat and line wrapping toggle handlers to the the global DOMContentLoaded handler, thus eliminating all inline javascript from the paper template. Differential Revision: https://phab.mercurial-scm.org/D3437
-
- May 01, 2018
-
-
Gregory Szorc authored
A side-effect of 98baf8dea553 was that the Content-Security-Policy header was set on all HTTP responses by default. This header wasn't in our list of allowed headers for HTTP 304 responses. This would trigger a ProgrammingError when a 304 response was issued via hgwebdir. This commit adds Content-Security-Policy to the allow list of headers for 304 responses so we no longer encounter the error. Differential Revision: https://phab.mercurial-scm.org/D3436
-
Gregory Szorc authored
A side-effect of 98baf8dea553 was that hgwebdir always sets a global default for the Content-Type header. HTTP 304 responses don't allow the Content-Type header. So a side-effect of this change was that HTTP 304 responses served via hgwebdir resulted in a ProgrammingError being raised. This commit teaches our 304 response issuing code to drop the Content-Type header. Differential Revision: https://phab.mercurial-scm.org/D3435
-
Gregory Szorc authored
There are two separate failures here. One for the Content-Type header. Another for the Content-Security-Policy header. Differential Revision: https://phab.mercurial-scm.org/D3434
-
- Apr 27, 2018
-
-
Gregory Szorc authored
Discussion in issue 5860 seems to indicate this can occur. Differential Revision: https://phab.mercurial-scm.org/D3432
-
- Apr 26, 2018
-
-
Yuya Nishihara authored
It's okay now, but we'll end up leaking daemon processes if we add some more.
-
Yuya Nishihara authored
-
- Apr 25, 2018
-
-
Gregory Szorc authored
The zstd compression engine requires C extensions and isn't present in pure Python builds. The compression engine list leaks into the server capabilities string. Unless we're testing functionality specific to a compression format, the set of compression formats supported by a server doesn't matter much. So this commit explicitly defines the server's compression engines for some tests so behavior is consistent between pure and non-pure builds. Differential Revision: https://phab.mercurial-scm.org/D3431
-
Augie Fackler authored
This side of the test got overlooked. We should probably consider having a way to run some of our tests through a "no-zstd" case just like we run some things through a "no-obsmarkers" case, but that's not an appropriate thing for stable. Differential Revision: https://phab.mercurial-scm.org/D3430
-
Augie Fackler authored
This doesn't fix everything in these two tests around missing zstd: we still get some changes in the CBOR payload in ways that I think we probably shouldn't bother to glob around. Maybe we should just disable zstd support in some of these lower-level wireproto tests? Differential Revision: https://phab.mercurial-scm.org/D3429
-
Martin von Zweigbergk authored
Without this patch, test-histedit-arguments.t would fail when run with --pure. It turned out to be because the pure version of _partialmatch() does not support full 40-byte hex nodeids. When histedit's instructions include things like "pick tip", it resolves the "tip" revision early to a full nodeid (but plain hex nodeid prefixes are not resolved to full nodeids). Then the nodeid (full or not) is looked up using to a full nodeid later. This step is what fails in pure mode. It has been failing since my c4131138eadb (histedit: look up partial nodeid as partial nodeid, 2018-04-06). I haven't verified, but I suspect histedit instructions like "pick <full hex nodeid>" would have been failing before my commit too, though. The fix is trivial: change a "< 40" to "<= 40". Differential Revision: https://phab.mercurial-scm.org/D3428
-
- Apr 24, 2018
-
-
Gregory Szorc authored
An unintended side-effect of f0a851542a05 was that the request body file object (which uses a util.cappedreader) was constructed twice when hgwebdir called into hgweb. Since we attempt to read all remaining data from this file object when Content-Length is defined and since there were two instances of this object and the client supplied no additional data to read, this resulted in deadlock. The fix implemented in this commit is to reuse the request body file object when it is passed from hgwebdir to hgweb. A test demonstrating `hg clone` and `hg push` via hgwebdir has been added. Without this patch, the test hangs when doing `hg clone`. Surprisingly, this must mean that we have effectively no test coverage of the wire protocol when run via hgwebdir. Differential Revision: https://phab.mercurial-scm.org/D3427
-
Pulkit Goyal authored
I still don't feel confident about locking the behavior of all the things in the remotenames extension. Moreover the extension was introduced in this cycle only. Let's mark this extension EXPERIMENTAL for now so that we can change things especially the storage layer if required in next cycle. I will like to use cbor at storage layer too. Differential Revision: https://phab.mercurial-scm.org/D3426
-
- Apr 25, 2018
-
-
Augie Fackler authored
I'm 99% sure this is a portable use of /bin/[, and it seems to fix the issue I noticed on the buildbot on my machine.
-
- Apr 24, 2018
-
-
Yuya Nishihara authored
-
Martin von Zweigbergk authored
This was failing our 4.6rc1 build like this: mercurial.error.RepoError: repository /tmp/build-debs.zMTRhC/src-4.6rc1 not found Differential Revision: https://phab.mercurial-scm.org/D3425
-
- Apr 23, 2018
-
-
Boris Feld authored
The output from devel-peer-request is expected to give data about request and roundtrip done to the server. Changeset a9cffd14aa04 changed some of that by grouping hello and between commands call. However, the old sequence of command was "emulated" in sshpeer. Update the sshpeer to reflect this grouping of commands and update the tests that use it.
-
- Apr 24, 2018
-
-
Matt Harbison authored
With the previous breakage tamed, the lack of test output difference was causing the test runner to report "no result code from test" because of this glob.
-
Matt Harbison authored
After loading up with status messages, I noticed that the subsequent matcher was rejecting 'scratch\mybranch' on Windows. No bookmarks were reported back, and the tests subsequently failed. I did a search for 'match', and nothing else looks like it needs to be fixed up, but someone who understands this code should also take a look. I also tried setting `infinitepush.branchpattern=re:scratch\\.*` in library-infinitepush.sh without this change, but that didn't work. Still, should we ban '\' in these bookmarks to avoid confusion? I thought I saw code that sandwiches a pattern between 're:^' and '.*', so perhaps regex characters will need special care? I also noticed comments in externalbundlestore.{read,write} that it won't work on Windows because of opening an open file. But I don't see a test failure, so this may lack test coverage.
-
- Apr 22, 2018
-
-
Gregory Szorc authored
The startup time of `hg` increased during the 4.6 development cycle. A cause of that was importing more modules and doing more work at module import time. The import of zope.interface and the declaring of various interfaces is partially responsible for the startup time regression. Our current usage of zope.interface doesn't do much at run time: we are merely declaring interfaces and stating that certain types implement various interfaces. Core Mercurial is not (yet) using of any of zope.interface features that actually require that interface plumbing be defined. The only place we actually need the interface metadata is in test-check-interfaces.py. This commit establishes a new interfaceutil module. It exposes the subset of the zope.interface API that we currently use. By default, the APIs no-op. But if an environment variable is set, we export the real zope.interface APIs. Existing importers of zope.interface have been converted to use the new module. test-check-interfaces.py has been updated to define the environment variable so the real zope.interface is used. The net effect of this change is we stop importing 9 zope.interface.* modules and we no longer perform interface bookkeeping when registering interfaces. On my i7-6700K on Linux, a shell loop that runs `hg log -r .` 300 times on a repo with 1 commit shows a significant CPU time improvement (average of 4 runs): 4.5: 14.814s before: 19.028s after: 16.945s And with `run-tests.py -j10` (single run): 4.5: ~3100s (~51.7m) before: ~4450s (~74.2m) after: ~3980s (~66.3m) So this claws back about half of the regressions in 4.6. Differential Revision: https://phab.mercurial-scm.org/D3419
-
- Apr 23, 2018
-
-
Yuya Nishihara authored
Appears that MSYS cp only copies mtime in seconds.
-
- Apr 20, 2018
-
-
Augie Fackler authored
-
durin42 authored
-
durin42 authored
-
Kim Alvefur authored
-
Yuya Nishihara authored
Historically we had had C extensions in mercurial/, which shadows the pure Python modules of the same name forever unless we do clean build/install. I'm sloppy to think about new name, so just dropped the "s".
-
- Apr 19, 2018
-
-
Yuya Nishihara authored
9e40bc4c1bde just says "harden testhunk." I don't think this would be the case, but it makes some sense to avoid negative index.
-
- Apr 20, 2018
-
-
Yuya Nishihara authored
-
- Apr 19, 2018
-
-
Tom Prince authored
Differential Revision: https://phab.mercurial-scm.org/D3414
-
Yuya Nishihara authored
I'm not young. "red dim" is nearly invisible, and "red" vs "red dim" is too subtle to see difference. And, "underline" is necessary to highlight whitespace changes.
-
Yuya Nishihara authored
Here we want to assert not 'mtime(foo.whole.orig) < mtime(foo.whole)'. The condition has to be inverted since 'f --newer' says "newer" if the mtimes match. Alternatively, we could insert 'sleep 2' before 'cp' to ensure that foo.whole.orig is newer than foo.whole, but a fewer sleeps should be better.
-
Yuya Nishihara authored
This partially backs out ecd3f6909184. It seems layering violation for repo[changeid] to raise storage-level exceptions transparently. Otherwise, we would have to rewrite callers to catch all of them. try: repo[rev_or_node] except (error.RepoLookupError, error.FilteredIndexError, error.FilteredLookupError): pass This would also fix filectx._changectx(), which catches FilteredRepoLookupError to fall back to the unfiltered path.
-
Yuya Nishihara authored
-