Fri, 06 Apr 2018 12:45:08 -0700 context: only bother looking for broken dirstate for 20-byte changeid
Martin von Zweigbergk <martinvonz@google.com> [Fri, 06 Apr 2018 12:45:08 -0700] rev 37855
context: only bother looking for broken dirstate for 20-byte changeid If we fail to look up a changeid in changectx.__init__, we check if it exactly matches any of the dirstate parents, and if it does, we print a more specific message ("working directory has unknown parent '...'!" instead of "unknown revision '...'"). The dirstate parents are always 20 bytes, so there's no need to check for a match when the given changeid is not 20 bytes. (And now that all the other allowed forms of changeid have been moved out of the constructor, there's no risk that a changeid that did match a dirstate parent was actually a valid bookmark.) Differential Revision: https://phab.mercurial-scm.org/D3450
Fri, 11 May 2018 20:10:22 +0900 revset: pass in lookup function to matchany() (issue5879) stable
Yuya Nishihara <yuya@tcha.org> [Fri, 11 May 2018 20:10:22 +0900] rev 37854
revset: pass in lookup function to matchany() (issue5879) Silly mistake in f83cb91b052e.
Fri, 11 May 2018 20:08:30 +0900 test-hgweb: add test for foo-bar name lookup stable
Yuya Nishihara <yuya@tcha.org> [Fri, 11 May 2018 20:08:30 +0900] rev 37853
test-hgweb: add test for foo-bar name lookup This is broken since f83cb91b052e "revset: pass in lookup function instead of repo (API)."
Sat, 28 Apr 2018 23:16:41 -0700 context: drop support for looking up context by ambiguous changeid (API)
Martin von Zweigbergk <martinvonz@google.com> [Sat, 28 Apr 2018 23:16:41 -0700] rev 37852
context: drop support for looking up context by ambiguous changeid (API) This removes support for using the changectx constructor (and thereby repo[x]) for looking up contexts by a stringified int, a namespace key (e.g. a bookmark), or a partial hex nodeid. This means that e.g. repo[<hex nodeid>] will now fail even if a bookmark with the same name exists (which is a good thing IMO). It also means that doing repo[<non-existent node>] no longer ends up loading namespaces (which was a surprising side-effect of creating of failing to create a context object that I recently ran into while debugging something unrelated to this series). Differential Revision: https://phab.mercurial-scm.org/D3449
Sat, 28 Apr 2018 23:54:07 -0700 tests: pass parent revision as integer to repo[x] in test-context-metadata.t
Martin von Zweigbergk <martinvonz@google.com> [Sat, 28 Apr 2018 23:54:07 -0700] rev 37851
tests: pass parent revision as integer to repo[x] in test-context-metadata.t Support for looking up by stringified int is going away. It's already deprecated, but I think I didn't notice this case because the test case pipes through `grep`. Differential Revision: https://phab.mercurial-scm.org/D3448
Sat, 05 May 2018 11:42:42 +0900 bookmarks: cache reverse mapping (issue5868)
Yuya Nishihara <yuya@tcha.org> [Sat, 05 May 2018 11:42:42 +0900] rev 37850
bookmarks: cache reverse mapping (issue5868) I chose a simpler implementation. If the initial cost of building reverse mapping is significant, we'll have to move it under @propertycache. The nodemap could be a dict of sets, but I think keeping a sorted list is better since each node is likely to have zero/one bookmark. Micro-benchmark with 1001 bookmarks and 1001 revisions: $ for n in `seq 0 1000`; do touch $n; hg book book$n; hg ci -qAm$n; done $ hg bookmarks --time > /dev/null (orig) time: real 0.040 secs (user 0.050+0.000 sys 0.000+0.000) (new) time: real 0.040 secs (user 0.040+0.000 sys 0.010+0.000) $ hg log -T '{bookmarks}\n' --time > /dev/null (orig) time: real 0.160 secs (user 0.160+0.000 sys 0.000+0.000) (new) time: real 0.090 secs (user 0.100+0.000 sys 0.000+0.000)
Sat, 05 May 2018 11:44:43 +0900 bookmarks: make argument names of _set/_del() more specific
Yuya Nishihara <yuya@tcha.org> [Sat, 05 May 2018 11:44:43 +0900] rev 37849
bookmarks: make argument names of _set/_del() more specific
Sat, 05 May 2018 11:34:03 +0900 bookmarks: extract function that looks up bookmark names by node
Yuya Nishihara <yuya@tcha.org> [Sat, 05 May 2018 11:34:03 +0900] rev 37848
bookmarks: extract function that looks up bookmark names by node
Sat, 05 May 2018 11:21:41 +0900 bookmarks: hide dict behind bmstore class
Yuya Nishihara <yuya@tcha.org> [Sat, 05 May 2018 11:21:41 +0900] rev 37847
bookmarks: hide dict behind bmstore class This should make it clearer that the bmstore doesn't expose all dict APIs.
Sat, 05 May 2018 19:00:03 -0700 tests: remove pid file by default
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 05 May 2018 19:00:03 -0700] rev 37846
tests: remove pid file by default Previously, killdaemons.py would kill PIDs listed in a file then leave the file lingering around. If the PIDs are killed, then there's no point leaving the PID file around. In the worst case, a later invocation of killdaemons.py (run-tests.py invokes killdaemons.py after running a test) could kill a separate process whose PID conflicted with a previously-killed process. By removing the PID file, we eliminate this possibility. Some tests were manually removing the PID file after calling killdaemons.py. So we update these tests to not do this. Differential Revision: https://phab.mercurial-scm.org/D3443
Mon, 30 Apr 2018 19:54:55 -0700 tests: remove #require killdaemons
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 30 Apr 2018 19:54:55 -0700] rev 37845
tests: remove #require killdaemons The killdaemons hghave feature has returned True since it was introduced in 448d0c452140. As such, "#require killdaemons" has no effect and is superfluous. So we remove instances of it. Differential Revision: https://phab.mercurial-scm.org/D3442
Sat, 05 May 2018 18:35:16 -0700 pycompat: export queue module instead of symbols in module (API)
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 05 May 2018 18:35:16 -0700] rev 37844
pycompat: export queue module instead of symbols in module (API) Previously, pycompat and util re-exported individual symbols from the queue module. This had the side-effect of forcing the loading of the queue module whenever pycompat/util was imported. These symbols aren't used very often. So importing the module to get a handle on the symbols is wasteful. This commit changes pycompat so it no longer exports the individual symbols in the queue module. Instead, we make the imported module a "public" symbol. We drop the individual symbol aliases from the util module. All consumers are updated to use pycompat.queue.* instead. This change makes 300 invocations of `hg log -r. -T '{rev}\n'` a little faster: before: 18.44s after: 17.87s Differential Revision: https://phab.mercurial-scm.org/D3441
Sat, 05 May 2018 18:41:51 -0700 demandimport: make module ignores a set (API)
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 05 May 2018 18:41:51 -0700] rev 37843
demandimport: make module ignores a set (API) The list of modules to ignore is used for membership testing. Yet it is defined as a list. Sets are more efficient for membership testing. So this commit converts the module list to a set. Since we took an API hit, I renamed the variable to further clarify the change. This appears to reduce the CPU time for running 300 invocations of `hg log -r. -T '{rev}'` on my i7-6700K: before: 18.64s after: 18.44s Differential Revision: https://phab.mercurial-scm.org/D3440
Tue, 08 May 2018 14:17:46 -0700 bundle2: mark the bundle2 part as advisory (issue5872) stable
Boris Feld <boris.feld@octobus.net> [Tue, 08 May 2018 14:17:46 -0700] rev 37842
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
Tue, 08 May 2018 11:39:38 +0200 debugbundle: also display if a part is mandatory or advisory stable
Boris Feld <boris.feld@octobus.net> [Tue, 08 May 2018 11:39:38 +0200] rev 37841
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
Thu, 19 Apr 2018 20:33:43 +0900 cmdutil: remove unused 'confirmopts' constant
Yuya Nishihara <yuya@tcha.org> [Thu, 19 Apr 2018 20:33:43 +0900] rev 37840
cmdutil: remove unused 'confirmopts' constant Follows up f10cb49951e1.
Thu, 03 May 2018 15:08:16 +0900 formatter: ditch namedtuple in favor of attr
Yuya Nishihara <yuya@tcha.org> [Thu, 03 May 2018 15:08:16 +0900] rev 37839
formatter: ditch namedtuple in favor of attr
Sun, 29 Apr 2018 15:52:01 +0900 log: consume --stat/patch options at constructor of changesetprinter
Yuya Nishihara <yuya@tcha.org> [Sun, 29 Apr 2018 15:52:01 +0900] rev 37838
log: consume --stat/patch options at constructor of changesetprinter The variable name, self.diffopts, was confusing. Let's split it to two booleans.
Sun, 29 Apr 2018 15:44:17 +0900 log: cache diffopts instance
Yuya Nishihara <yuya@tcha.org> [Sun, 29 Apr 2018 15:44:17 +0900] rev 37837
log: cache diffopts instance It appears that calling patch.diff*opts() repeatedly has some cost. $ hg log -T '{rev}\n' -R mercurial --time > /dev/null (orig) time: real 4.430 secs (user 4.370+0.000 sys 0.050+0.000) (new) time: real 1.950 secs (user 1.880+0.000 sys 0.060+0.000) 'diffopts or {}' isn't necessary as patch.diff*opts() accepts opts=None.
Sat, 05 May 2018 18:06:45 -0700 merge with stable
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 05 May 2018 18:06:45 -0700] rev 37836
merge with stable
Sat, 05 May 2018 18:03:01 -0500 Added signature for changeset 6614cac550ae stable
Kevin Bullock <kbullock@ringworld.org> [Sat, 05 May 2018 18:03:01 -0500] rev 37835
Added signature for changeset 6614cac550ae
Sat, 05 May 2018 18:02:59 -0500 Added tag 4.6 for changeset 6614cac550ae stable
Kevin Bullock <kbullock@ringworld.org> [Sat, 05 May 2018 18:02:59 -0500] rev 37834
Added tag 4.6 for changeset 6614cac550ae
Thu, 30 Nov 2017 21:19:46 -0500 filelog: don't crash on invalid copy metadata (issue5748) stable 4.6
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 30 Nov 2017 21:19:46 -0500] rev 37833
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.
Mon, 30 Apr 2018 15:32:11 -0700 httppeer: detect redirect to URL without query string (issue5860) stable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 30 Apr 2018 15:32:11 -0700] rev 37832
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
Thu, 03 May 2018 14:43:25 +0900 hgweb: prevent triggering dummy href="#" handler stable
Yuya Nishihara <yuya@tcha.org> [Thu, 03 May 2018 14:43:25 +0900] rev 37831
hgweb: prevent triggering dummy href="#" handler Follow up for the previous patch.
Wed, 02 May 2018 21:00:43 -0700 paper: add href="#" to links with click handlers stable
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 02 May 2018 21:00:43 -0700] rev 37830
paper: add href="#" to links with click handlers This restores the styling that was accidentally removed by the previous change to these files. Differential Revision: https://phab.mercurial-scm.org/D3438
Wed, 02 May 2018 19:16:01 -0700 paper: don't register click handlers with inline javascript (issue5812) stable
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 02 May 2018 19:16:01 -0700] rev 37829
paper: don't register click handlers with inline javascript (issue5812) 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
Mon, 30 Apr 2018 17:28:59 -0700 hgweb: allow Content-Security-Policy header on 304 responses (issue5844) stable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 30 Apr 2018 17:28:59 -0700] rev 37828
hgweb: allow Content-Security-Policy header on 304 responses (issue5844) 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
Mon, 30 Apr 2018 17:22:20 -0700 hgweb: discard Content-Type header for 304 responses (issue5844) stable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 30 Apr 2018 17:22:20 -0700] rev 37827
hgweb: discard Content-Type header for 304 responses (issue5844) 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
Mon, 30 Apr 2018 17:08:56 -0700 tests: add tests demonstrating ISE for HTTP 304 responses with hgwebdir stable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 30 Apr 2018 17:08:56 -0700] rev 37826
tests: add tests demonstrating ISE for HTTP 304 responses with hgwebdir 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
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip