This is an archive of the discontinued Mercurial Phabricator instance.

wireproto: port pushkey command to wire protocol version 2
ClosedPublic

Authored by indygreg on Apr 9 2018, 2:58 PM.

Details

Summary

It doesn't do output redirection yet. And I'd love to generally overhaul
the pushkey protocol for wire protocol version 2. But this will be a bit
of effort. Let's do it as a follow-up.

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

indygreg created this revision.Apr 9 2018, 2:58 PM
durin42 added a subscriber: durin42.Apr 9 2018, 6:27 PM
durin42 added inline comments.
tests/test-wireproto-command-pushkey.t
2

You can't fuse this with an existing test to avoid overhead of creating a repo etc? The testsuite has started growing precipitously again with a lot of narrowly-focussed tests, and I wonder if we should try and be a little more unified about having a single big "test wireprotov2".t file...

indygreg added inline comments.Apr 9 2018, 7:21 PM
tests/test-wireproto-command-pushkey.t
2

And at the same time having giant test files makes it difficult to refactor an existing test file because tests below change due to differences above. You end up doing all kinds of strips, etc to undo changes so you don't have to change the entire test file.

Also, is there evidence that repo creation overhead is a problem? We're not doing fsync() as part of repo creation. I'm finding it difficult to believe that repo creation or .t file existence is a big deal. I understand the theoretically concern. But for developers (who presumably have reasonable I/O on development machines), I'd expect Python + hg process startup overhead to dwarf all other performance concerns.

durin42 added inline comments.Apr 11 2018, 12:28 PM
tests/test-wireproto-command-pushkey.t
2

We're going to go ahead with this as written now, but everyone should be aware that we're approaching a crisis of sorts when it comes to test execution time, especially on non-Linux platforms. We've had people reporting -j8 runs on macOS taking well over an hour.

I hope to find some time to tackle this in the next cycle.

This revision was automatically updated to reflect the committed changes.