Thu, 01 Feb 2018 19:32:42 -0800 httppeer: change logic around argument handling
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 01 Feb 2018 19:32:42 -0800] rev 36218
httppeer: change logic around argument handling The code to process arguments only makes sense if there are arguments. So change an "else" to "elif args", remove an "if" that isn't necessary, and add some docs for good measure. Differential Revision: https://phab.mercurial-scm.org/D2214
Mon, 12 Feb 2018 16:35:06 -0800 tests: test using both versions of SSH protocol
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 12 Feb 2018 16:35:06 -0800] rev 36217
tests: test using both versions of SSH protocol Now that the version 2 of the SSH protocol is usable in core, we can start actively testing it more widely outside of low-level protocol tests. We add #testcases variants to a handful of tests so we exercise both version 1 and version 2 of the SSH protocol when testing. This will allow us to more easily find regressions and variances as protocol 2 is developed. It will also make it easier to continue testing with protocol version 1 once version 2 is enabled by default. There are a handful of tests using ssh:// that should also gain test variances. One - test-push-race.t - already has a #testcases. This would require combinatorial cases. I didn't want to go down that rabbit hole, so that test is unchanged. Thinking aloud, there is probably an opportunity to automatically run tests with multiple server/protocol implementations. Ideally any test that performed server interaction would run with all supported server implementations and protocols so we could find variances between servers and protocols. But this has been a long-standing issue with our test harness. I don't think it is an easily solved problem. But it would be nice... Differential Revision: https://phab.mercurial-scm.org/D2206
Thu, 08 Feb 2018 11:39:23 -0800 sshpeer: log remote capabilities after protocol upgrade
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 08 Feb 2018 11:39:23 -0800] rev 36216
sshpeer: log remote capabilities after protocol upgrade This helps reduce variance with version 1 and will help prevent test output divergence as we start testing protocol version 2 more widely. Differential Revision: https://phab.mercurial-scm.org/D2205
Mon, 12 Feb 2018 16:33:54 -0800 wireprotoserver: handle SSH protocol version 2 upgrade requests
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 12 Feb 2018 16:33:54 -0800] rev 36215
wireprotoserver: handle SSH protocol version 2 upgrade requests This commit teaches the SSH server to recognize the "upgrade" request line that clients send when they wish to switch the channel to version 2 of the SSH protocol. Servers don't honor upgrade requests unless an experimental config option is set. Since the built-in server now supports upgrade requests, our test server to test the handshake has been deleted. Existing tests use the built-in server and their output doesn't change. The upgrade is handled in our state machine. The end result is a bit wonky, as the server transitions back to version 1 state immediately after upgrading. But this will change as soon as version 2 has an actual protocol that differs from version 1. Tests demonstrating that the new server is a bit more strict about the upgrade handshake have been added. Differential Revision: https://phab.mercurial-scm.org/D2204
Thu, 08 Feb 2018 15:09:59 -0800 wireprotoserver: move SSH server operation to a standalone function
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 08 Feb 2018 15:09:59 -0800] rev 36214
wireprotoserver: move SSH server operation to a standalone function The server-side processing logic will soon get a bit more complicated in order to handle protocol switches. We will use a state machine to help make the transitions clearer. To prepare for this, we move SSH server operation into a standalone function. We structure it as a very simple state machine. It only has two states for now, with one state containing the bulk of the logic. But things will evolve shortly. Differential Revision: https://phab.mercurial-scm.org/D2203
Wed, 14 Feb 2018 17:35:13 -0700 py3: stringify integer with %d instead of bytes()
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 14 Feb 2018 17:35:13 -0700] rev 36213
py3: stringify integer with %d instead of bytes() The unbundle wire protocol command now returns a properly formatted reply in Python 3. Differential Revision: https://phab.mercurial-scm.org/D2274
Wed, 14 Feb 2018 17:23:26 -0700 py3: add b'' to test-sshserver.py
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 14 Feb 2018 17:23:26 -0700] rev 36212
py3: add b'' to test-sshserver.py # skip-blame because adding b'' prefixes Differential Revision: https://phab.mercurial-scm.org/D2273
Wed, 14 Feb 2018 17:21:42 -0700 py3: add b'' to config options in test extension
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 14 Feb 2018 17:21:42 -0700] rev 36211
py3: add b'' to config options in test extension # skip-blame because just b'' prefixes Differential Revision: https://phab.mercurial-scm.org/D2272
Tue, 13 Feb 2018 14:15:29 -0800 manifest: add support for including directories outside narrowspec
Martin von Zweigbergk <martinvonz@google.com> [Tue, 13 Feb 2018 14:15:29 -0800] rev 36210
manifest: add support for including directories outside narrowspec When using tree manifests and the client doesn't have a directory, we have two choices for what to do with "hg manifest" output: 1) ignore the directory, and 2) include the directory (not files within it). For "hg files", we decided to ignore the directories (and files) outside the narrowspec. If we choose to not include directories outside the narrowspec, then I think we should also make sure we don't include files outside the narrowspec. I also think we should add --outside-narrow flag (or other name). Thus, whichever way we go, I think we should have a way of displaying paths (files or directories) outside the narrowspec. For that we'll need to handle the 't' flag that narrowhg uses, and that's what this patch adds support for. Differential Revision: https://phab.mercurial-scm.org/D2235
Tue, 13 Feb 2018 13:50:24 -0800 narrow: restrict manifest iteration by using manifest.walk(matcher)
Martin von Zweigbergk <martinvonz@google.com> [Tue, 13 Feb 2018 13:50:24 -0800] rev 36209
narrow: restrict manifest iteration by using manifest.walk(matcher) This is only for root nodes, so it shouldn't really matter (they're rarely huge), but seems cleaner. Differential Revision: https://phab.mercurial-scm.org/D2234
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip