- Jan 18, 2022
-
-
Pierre-Yves David authored
The value of `streamreqs` changes depending of the format used, but this is not relevant for this tests. So we doing a smarter matching of the line to avoid this test interfering with format changes in the future. Differential Revision: https://phab.mercurial-scm.org/D12080
-
Pierre-Yves David authored
The value of `streamreqs` changes depending of the format used, but this is not relevant for this tests. So we doing a smarter matching of the line to avoid this test interfering with format changes in the future. Differential Revision: https://phab.mercurial-scm.org/D12079
-
Pierre-Yves David authored
The value of `streamreqs` changes depending of the format used, but this is not relevant for this tests. So we doing a smarter matching of the line to avoid this test interfering with format changes in the future. Differential Revision: https://phab.mercurial-scm.org/D12078
-
Pierre-Yves David authored
The value of `streamreqs` changes depending of the format used, but this is not relevant for this tests. So we doing a smarter matching of the line to avoid this test interfering with format changes in the future. Differential Revision: https://phab.mercurial-scm.org/D12077
-
- Jan 24, 2022
-
-
Pierre-Yves David authored
Same rational as the previous commit about test-bundle.t. These line are quite volatile and having dedicated block will make their update clearer and simpler. Differential Revision: https://phab.mercurial-scm.org/D12076
-
- Jan 18, 2022
-
-
Pierre-Yves David authored
Having conditional line matching for this kind of big block is quite inconvenient to update. The new way should be simpler to maintain. Differential Revision: https://phab.mercurial-scm.org/D12075
-
- Jan 24, 2022
-
-
Pierre-Yves David authored
Now that socket closing are decided much closer to the actual closure, we can use fuzzy matching for this part of the exchange that changes on a regular basis. This should make fixing bug in stream requirements and enabling new format much simpler. Differential Revision: https://phab.mercurial-scm.org/D12074
-
- Jan 21, 2022
-
-
Pierre-Yves David authored
This test case is now less sensitive to change of unrelated bits of the client/server exchange. Since this introduce some churn in the output, we do it independently for each test cases. This patch is the last of such changes, for both sent and recv cases. Differential Revision: https://phab.mercurial-scm.org/D12073
-
Pierre-Yves David authored
This test case is now less sensitive to change of unrelated bits of the client/server exchange. Since this introduce some churn in the output, we do it independently for each test cases. Differential Revision: https://phab.mercurial-scm.org/D12072
-
Pierre-Yves David authored
This test case is now less sensitive to change of unrelated bits of the client/server exchange. Since this introduce some churn in the output, we do it independently for each test cases. Differential Revision: https://phab.mercurial-scm.org/D12071
-
Pierre-Yves David authored
This test case is now less sensitive to change of unrelated bits of the client/server exchange. Since this introduce some churn in the output, we do it independently for each test cases. Differential Revision: https://phab.mercurial-scm.org/D12070
-
- Jan 23, 2022
-
-
Pierre-Yves David authored
This test case is now less sensitive to change of unrelated bits of the client/server exchange. Since this introduce some churn in the output, we do it independently for each test cases. Differential Revision: https://phab.mercurial-scm.org/D12069
-
Pierre-Yves David authored
We introduce the `close-after-recv-patterns` option. It has the same goal as `close-after-send-patterns` with a slightly different implementation. Reading "up to a pattern" is hard. As we can only check the pattern from what we have already read (inlike writing, were we can check what we are about to write). So instead we make the `close-after-recv-patterns` alter the behavior of the existing `close-after-recv-bytes`. The value from `close-after-recv-bytes` only gets into play after we have seen the pattern from `close-after-recv-patterns`. This allow us to achieve the target benefit without changing the read pattern too much. Differential Revision: https://phab.mercurial-scm.org/D12068
-
- Jan 21, 2022
-
-
Pierre-Yves David authored
This specific test case is now using the new "close when a pattern is seen" approach compared to the more fragile "that many bytes were sent" approach. Since such change are still a bit noisy, we split each change in there own changesets. Differential Revision: https://phab.mercurial-scm.org/D12067
-
Pierre-Yves David authored
This specific test case is now using the new "close when a pattern is seen" approach compared to the more fragile "that many bytes were sent" approach. Since such change are still a bit noisy, we split each change in there own changesets. Differential Revision: https://phab.mercurial-scm.org/D12066
-
Pierre-Yves David authored
This specific test case is now using the new "close when a pattern is seen" approach compared to the more fragile "that many bytes were sent" approach. Since such change are still a bit noisy, we split each change in there own changesets. Differential Revision: https://phab.mercurial-scm.org/D12065
-
Pierre-Yves David authored
This specific test case is now using the new "close when a pattern is seen" approach compared to the more fragile "that many bytes were sent" approach. Since such change are still a bit noisy, we split each change in there own changesets. Differential Revision: https://phab.mercurial-scm.org/D12064
-
Pierre-Yves David authored
This specific test case is now using the new "close when a pattern is seen" approach compared to the more fragile "that many bytes were sent" approach. Since such change are still a bit noisy, we split each change in there own changesets. Differential Revision: https://phab.mercurial-scm.org/D12063
-
Pierre-Yves David authored
This specific test case is now using the new "close when a pattern is seen" approach compared to the more fragile "that many bytes were sent" approach. Since such change are still a bit noisy, we split each change in there own changesets. Differential Revision: https://phab.mercurial-scm.org/D12062
-
Pierre-Yves David authored
This specific test case is now using the new "close when a pattern is seen" approach compared to the more fragile "that many bytes were sent" approach. Since such change are still a bit noisy, we split each change in there own changesets. Differential Revision: https://phab.mercurial-scm.org/D12061
-
Pierre-Yves David authored
This specific test case is now using the new "close when a pattern is seen" approach compared to the more fragile "that many bytes were sent" approach. Since such change are still a bit noisy, we split each change in there own changesets. Differential Revision: https://phab.mercurial-scm.org/D12060
-
Pierre-Yves David authored
This specific test case is now using the new "close when a pattern is seen" approach compared to the more fragile "that many bytes were sent" approach. Since such change are still a bit noisy, we split each change in there own changesets. Differential Revision: https://phab.mercurial-scm.org/D12059
-
Pierre-Yves David authored
This specific test case is now using the new "close when a pattern is seen" approach compared to the more fragile "that many bytes were sent" approach. Since such change are still a bit noisy, we split each change in there own changesets. Differential Revision: https://phab.mercurial-scm.org/D12058
-
Pierre-Yves David authored
This specific test case is now using the new "close when a pattern is seen" approach compared to the more fragile "that many bytes were sent" approach. Since such change are still a bit noisy, we split each change in there own changesets. Differential Revision: https://phab.mercurial-scm.org/D12057
-
- Jan 22, 2022
-
-
Pierre-Yves David authored
This specific test case is now using the new "close when a pattern is seen" approach compared to the more fragile "that many bytes were sent" approach. Since such change are still a bit noisy, we split each change in there own changesets. Differential Revision: https://phab.mercurial-scm.org/D12056
-
- Jan 21, 2022
-
-
Pierre-Yves David authored
This specific test case is now using the new "close when a pattern is seen" approach compared to the more fragile "that many bytes were sent" approach. Since such change are still a bit noisy, we split each change in there own changesets. Differential Revision: https://phab.mercurial-scm.org/D12055
-
- Jan 23, 2022
-
-
Pierre-Yves David authored
We want to check that we stop writing when we want to stop writing. Differential Revision: https://phab.mercurial-scm.org/D12054
-
- Jan 21, 2022
-
-
Pierre-Yves David authored
This specific test case is now using the new "close when a pattern is seen" approach compared to the more fragile "that many bytes were sent" approach. Since such change are still a bit noisy, we split each change in there own changesets. Differential Revision: https://phab.mercurial-scm.org/D12053
-
Pierre-Yves David authored
This specific test case is now using the new "close when a pattern is seen" approach compared to the more fragile "that many bytes were sent" approach. Since such change are still a bit noisy, we split each change in there own changesets. Differential Revision: https://phab.mercurial-scm.org/D12052
-
Pierre-Yves David authored
This specific test case is now using the new "close when a pattern is seen" approach compared to the more fragile "that many bytes were sent" approach. Since such change are still a bit noisy, we split each change in there own changesets. Differential Revision: https://phab.mercurial-scm.org/D12051
-
Pierre-Yves David authored
This specific test case is now using the new "close when a pattern is seen" approach compared to the more fragile "that many bytes were sent" approach. Since such change are still a bit noisy, we split each change in there own changesets. Differential Revision: https://phab.mercurial-scm.org/D12050
-
- Jan 22, 2022
-
-
Pierre-Yves David authored
Instead of using a fixed number a bytes, a very unstable method. We introduce a new config that can define a regex. One this regex is detected, nothing after it will be written and the socket will be closed. Tests will be migrated to this new method in later changesets. Differential Revision: https://phab.mercurial-scm.org/D12049
-
Pierre-Yves David authored
I don't really expect this doc to be read a lot, but mentioning that this is a list seems important. Differential Revision: https://phab.mercurial-scm.org/D12048
-
- Jan 21, 2022
-
-
Pierre-Yves David authored
Our ultimate goal is to add another way to define the connection needs to be closed. To do so, we need the "read" code to be more unified. Differential Revision: https://phab.mercurial-scm.org/D12047
-
Pierre-Yves David authored
This is the default block value that we use here and it make the output overall less readable. So we replace it with `~` Differential Revision: https://phab.mercurial-scm.org/D12046
-
Pierre-Yves David authored
Our ultimate goal is to add another way to define the connection needs to be closed. To do so, we need the "read" code to be more unified. Differential Revision: https://phab.mercurial-scm.org/D12045
-
Pierre-Yves David authored
This will make sure both `read` and `readline` do the same processing and make it simpler to update that processing in the future. Differential Revision: https://phab.mercurial-scm.org/D12044
-
- Jan 20, 2022
-
-
Pierre-Yves David authored
This will make sure both `sendall` and `write` do the same processing and make it simpler to update that processing in the future. Differential Revision: https://phab.mercurial-scm.org/D12043
-
- Jan 23, 2022
-
-
Pierre-Yves David authored
The `write` function was logging before calling the function while the `sendall` function were logging after calling the function. We align the `write` behavior on the `sendall` behavior before unifying the code. Differential Revision: https://phab.mercurial-scm.org/D12042
-
- Jan 21, 2022
-
-
Pierre-Yves David authored
In order to make the logic more advanced, we need to unify it. To unify it, we introduce a small object that will be responsible for tracking and enforcing "premature socket close" conditions for both proxy object (socketproxy and fileobjectproxy). More logic will be moved into the object in later changesets. Differential Revision: https://phab.mercurial-scm.org/D12041
-