test-http-bad-server: replace the default 65537 value in output 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

test-http-bad-server: refactor the reading logic to avoid early return 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

test-http-bad-server: factor code dealing with "read" in the new object 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

test-http-bad-server: factor code dealing with "write" in the new object 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

test-http-bad-server: unify log printing for `sendall` and `write` 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

test-http-bad-server: track close condition in an object 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

test-http-bad-server: use more readable name for variable This make the code more accessible overall. Differential Revision: https://phab.mercurial-scm.org/D12040

test-http-bad-server: align output by using `;` This is the only message using a `,` instead of `;` and that seems unintentional. I am unifying the message before unigying the code. Differential Revision: https://phab.mercurial-scm.org/D12039

test-http-bad-server: highlight each test with section Small "documentation" change to highlight each individual tests better. Differential Revision: https://phab.mercurial-scm.org/D12038

test-http-bad-server: rename config to use `-` This make things much more readable. Differential Revision: https://phab.mercurial-scm.org/D12037

test-http-bad-server: move the extension in `testlib` This seems like a better location for it. Differential Revision: https://phab.mercurial-scm.org/D12036

requirements: remove the `localrepo.supportedformat` attribute It is not longer used anywhere. Differential Revision: https://phab.mercurial-scm.org/D12035

requirements: sort _basesupported This will make the next changeset clearer. Differential Revision: https://phab.mercurial-scm.org/D12034

requirements: move the comment about manifestv2 in the module This is about requirements, so lets put it into the requirements module. We are about to remove code it was previously attached too. Differential Revision: https://phab.mercurial-scm.org/D12033

stream-clone: add a explicit set list requirements relevant to stream clone This set explicitly lists all the requirements that "stream clone" will preserve. Any other one will not be preserved. The role of listing the relevant one was previously filled by `repo.supportedformat`, but it seems clearer to use that such global and explicit set. The `repo.supportedformat` attribute will be cleaned up in a later changeset The true meaning of `repo.supportedformat` vs `repo._basesupported` was lost over time so, the content is currently bad. For example, `dirstate-v2` is currently considered relevant to the stream clone, or internal phase is missing. We kept the same content in this changeset and we will fix them later. Differential Revision: https://phab.mercurial-scm.org/D12032

stream-clone: filter possible missing requirements using all supported one The `supportedformat` requirements is missing some important requirements and it seems better to filter out with all requirements we know, not just an "arbitrary" subset. This is especially relevant as we about to phase out the `supportedformat` class attribute. (a backport of this change to stable should be sent soon). Differential Revision: https://phab.mercurial-scm.org/D12031

requirements: move "bookmark in store" requirements in the right module There seems to be no reasons to not have it with the others. Differential Revision: https://phab.mercurial-scm.org/D12030

stream-clone: add a explicit test for format change during stream clone They are different kind of requirements, the one which impact the data storage and are relevant to the files being streamed and the one which does not. For example some requirements are only relevant to the working copy, like sparse, or dirstate-v2. Since they are irrelevant to the content being streamed, they do not prevent the receiving side to use streaming clone and mercurial skip adverting them over the wire and, ideally, within the bundle. In addition, this let the client decide to use whichever format it desire for the part that does not affect the store itself. So the configuration related to these format are used as normal when doing a streaming clone. In practice, the feature was not really tested and is badly broken with bundle-2, since the requirements are not filtered out from the stream bundle. So we start with adding simple tests as a good base before the fix and adjust the feature. Differential Revision: https://phab.mercurial-scm.org/D12029

stream-clone: factor computation of requirement of a stream clone This gather code duplicated in multiple place and will make it easier to modify it safely in the future. Differential Revision: https://phab.mercurial-scm.org/D12028

stream-clone: factor computation of new clone requirement out This gather code duplicated in multiple place and will make it easier to modify it safely in the future. Differential Revision: https://phab.mercurial-scm.org/D12027

stream-clone: drop some outdated lines in test-stream-bundle-v2.t These line refer to a "dirstate-v2" variant that is no longer in use. The associated line drifted out of sync with reality. Differential Revision: https://phab.mercurial-scm.org/D12026

relnotes: add note about changed labels texts Differential Revision: https://phab.mercurial-scm.org/D12085

graft: attempt to make merge labels more helpful Differential Revision: https://phab.mercurial-scm.org/D12025

shelve: attempt to make merge labels more helpful Differential Revision: https://phab.mercurial-scm.org/D12024

histedit: attempt to make merge labels more helpful Differential Revision: https://phab.mercurial-scm.org/D12023

update: set custom conflict label for base commit Differential Revision: https://phab.mercurial-scm.org/D12022

merge: set custom conflict label for base commit Differential Revision: https://phab.mercurial-scm.org/D12021

rebase: set custom conflict label for base commit Differential Revision: https://phab.mercurial-scm.org/D12020

simplemerge: take over formatting of label from `filemerge` The padding we do of conflict labels depends on which conflict marker style is used. For two-way conflict markers (the default), the length of the base label shouldn't matter. It does before this patch, however. This patch moves the formatting from `filemerge` to `simplemerge`. The latter knows which conflict marker style to use, so it can easily decide about the padding. This change will allow us to use more descriptive "base" labels without causing illogical padding in 2-way markers. I'll do that next. One wrinkle is that we pass the same labels to external merge tools. I decided to change that in this patch to be simpler: no padding, and no ellipsis to fit within 80 columns. My reasoning is that the typical external, 3-or-4-panel merge tool doesn't show the labels on top of each others, so the padding doesn't make sense there. The ellipsis is probably not necessary because the external tools probably have their own way of dealing with long labels. Also, we limit them to "80 - 8" to fit the "<<<<<<< " before, which is almost definitely not what an external tool would put there. Differential Revision: https://phab.mercurial-scm.org/D12019

filemerge: pass `simplemerge.MergeInput` to tool functions Differential Revision: https://phab.mercurial-scm.org/D12018