url: add some defensive asserts on expected incoming types
Our type handling is a nightmare here, and we're loading passwords to
do network IO, so we can afford to be potentially-slow but pedantic
here.
Differential Revision: https://phab.mercurial-scm.org/D5734
changegroup: don't try to build changelog chunks if not required
When we extend a narrow clone without ellipsis, we don't download changelog
information because that's already present with the client. However we still try
to build that chunk stream. Building that chunk stream involves calling a lookup
function and store.emitrevisions() API. The lookup function is called len(cl)
number of times.
On large repositories, where len(cl) is in millions, calling that lookup
function is not a good idea. Also it's not required to use the
store.emitrevisons() API because we already have nodes present which we can use.
This patch short-circuits state building logic if we are processing a
non-ellipsis case and changelog is not required.
This saves up ~20 seconds on our internal repo for a single extend call.
Differential Revision: https://phab.mercurial-scm.org/D5733
revlog: make sure we never use sparserevlog without general delta (
issue6056)
We are getting user report where the delta code tries to use `sparse-revlog`
logic on repository where `generaldelta` is disabled. This can't work so we
ensure the two booleans have a consistent value.
Creating this kind of repository is not expected to be possible the current bug
report point at a clonebundle related bug that is still to be properly isolated
(Yuya Nishihara seems to a have done it).
Corrupting a repository to reproduce the issue is possible. A test using this
method is included in this fix.
sparserevlog: document the config option
This was overlooked when this graduated from experimental.
changegroup: initialize the state variable a bit earlier
This will make the next patch much easier.
Differential Revision: https://phab.mercurial-scm.org/D5732
tests: conditionalize test output on Python 3.7
Python 3.7 changed behavior of urllib.parse.quote() from RFC 2396
to RFC 3986 and ~ is now in the set of reserved characters and
isn't escaped.
We conditioanlize test output accordingly.
Differential Revision: https://phab.mercurial-scm.org/D5717
hghave: add pyXY features for Python version numbers
This will allow us to sniff for Python >= versions in tests.
Differential Revision: https://phab.mercurial-scm.org/D5088
py3: whitelist couple more passing tests found by buildbot
Differential Revision: https://phab.mercurial-scm.org/D5731
keepalive: implement _close_conn() so closes are known
Keepalives were not working on Python 3 because
http.client.HTTPResponse was refactored to call _close_conn()
instead of close(). Our custom close() is what returns inactive
connections to the available state.
We better support Python 3 by implementing a _close_conn().
Differential Revision: https://phab.mercurial-scm.org/D5720
lfs: explicitly add the Content-Length header when uploading blobs, for py3
This was the reason for test-lfs-test-server.t#git-server complaining about an
"invalid byte in chunk length". For some reason if this isn't explicitly added,
py3.7.1 is adding `transfer-encoding: chunked` as well as `Content-length: x`.
Wireshark flagged this as malformed. However, if this is set, it doesn't bother
with `transfer-encoding`.
Before this patch with py3:
PUT /objects/
31cf46fbc4ecd458a0943c5b4881f1f5a6dd36c53d6167d5b69ac45149b38e5b HTTP/1.1
Accept-Encoding: identity
Content-length: 12
accept: application/vnd.git-lfs
content-type: application/octet-stream
host: localhost:20062
transfer-encoding: chunked
user-agent: git-lfs/2.3.4 (Mercurial 4.9rc0+149-
7eb7637e34bf)
Before this patch with py27:
PUT /objects/
31cf46fbc4ecd458a0943c5b4881f1f5a6dd36c53d6167d5b69ac45149b38e5b HTTP/1.1
Accept-Encoding: identity
accept: application/vnd.git-lfs
content-type: application/octet-stream
content-length: 12
host: localhost:20062
user-agent: git-lfs/2.3.4 (Mercurial 4.9rc0+149-
7eb7637e34bf+
20190128)
With this patch and py3, the content is the same as the py27 example. RFC2616
says to ignore `Content-Length` if `Transfer-Encoding` is present, so maybe
there's nothing to do in the hg-server side (though I'm not sure which it is
using if presented both).
Maybe chunked encoding is better to do? If someone knows how to suppress the
`Content-Length`, we can try that instead.