Tue, 29 Jan 2019 16:03:52 +0300 changegroup: don't try to build changelog chunks if not required
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 29 Jan 2019 16:03:52 +0300] rev 41448
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
Thu, 24 Jan 2019 18:22:47 -0500 revlog: make sure we never use sparserevlog without general delta (issue6056) stable
Boris Feld <boris.feld@octobus.net> [Thu, 24 Jan 2019 18:22:47 -0500] rev 41447
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.
Wed, 30 Jan 2019 18:15:38 +0100 sparserevlog: document the config option stable
Boris Feld <boris.feld@octobus.net> [Wed, 30 Jan 2019 18:15:38 +0100] rev 41446
sparserevlog: document the config option This was overlooked when this graduated from experimental.
Tue, 29 Jan 2019 15:43:02 +0300 changegroup: initialize the state variable a bit earlier
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 29 Jan 2019 15:43:02 +0300] rev 41445
changegroup: initialize the state variable a bit earlier This will make the next patch much easier. Differential Revision: https://phab.mercurial-scm.org/D5732
Sat, 26 Jan 2019 11:23:31 -0800 tests: conditionalize test output on Python 3.7
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 26 Jan 2019 11:23:31 -0800] rev 41444
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
Sat, 13 Oct 2018 16:53:43 +0200 hghave: add pyXY features for Python version numbers
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 13 Oct 2018 16:53:43 +0200] rev 41443
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
Tue, 29 Jan 2019 14:30:10 +0300 py3: whitelist couple more passing tests found by buildbot
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 29 Jan 2019 14:30:10 +0300] rev 41442
py3: whitelist couple more passing tests found by buildbot Differential Revision: https://phab.mercurial-scm.org/D5731
Sat, 26 Jan 2019 13:52:39 -0800 keepalive: implement _close_conn() so closes are known
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 26 Jan 2019 13:52:39 -0800] rev 41441
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
Mon, 28 Jan 2019 21:35:06 -0500 lfs: explicitly add the Content-Length header when uploading blobs, for py3
Matt Harbison <matt_harbison@yahoo.com> [Mon, 28 Jan 2019 21:35:06 -0500] rev 41440
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.
Mon, 28 Jan 2019 03:20:31 -0500 perf: support looking up multiple revisions
Boris Feld <boris.feld@octobus.net> [Mon, 28 Jan 2019 03:20:31 -0500] rev 41439
perf: support looking up multiple revisions The nodemap code has optimisations around the number of lookup we actually made. As a result, being able to specify multiple revisions to look up is important when measuring performances. One can now specify full revspecs with the --rev arguments.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip