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.
Details
- Reviewers
- None
- Group Reviewers
hg-reviewers - Commits
- rHGbe5d4749edc0: wireproto: port pushkey command to wire protocol version 2
Diff Detail
- Repository
- rHG Mercurial
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Event Timeline
tests/test-wireproto-command-pushkey.t | ||
---|---|---|
1 | 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... |
tests/test-wireproto-command-pushkey.t | ||
---|---|---|
1 | 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. |
tests/test-wireproto-command-pushkey.t | ||
---|---|---|
1 | 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. |
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...