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
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.
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)."
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
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
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)
Yuya Nishihara <yuya@tcha.org> [Sat, 05 May 2018 11:44:43 +0900] rev 37849
bookmarks: make argument names of _set/_del() more specific
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
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.
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
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
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
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
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
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
Yuya Nishihara <yuya@tcha.org> [Thu, 19 Apr 2018 20:33:43 +0900] rev 37840
cmdutil: remove unused 'confirmopts' constant
Follows up
f10cb49951e1.
Yuya Nishihara <yuya@tcha.org> [Thu, 03 May 2018 15:08:16 +0900] rev 37839
formatter: ditch namedtuple in favor of attr
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.
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.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 05 May 2018 18:06:45 -0700] rev 37836
merge with stable
Kevin Bullock <kbullock@ringworld.org> [Sat, 05 May 2018 18:03:01 -0500] rev 37835
Added signature for changeset
6614cac550ae
Kevin Bullock <kbullock@ringworld.org> [Sat, 05 May 2018 18:02:59 -0500] rev 37834
Added tag 4.6 for changeset
6614cac550ae
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.
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
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.
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
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
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
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
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