upgrade: move descriptions and selection logic in individual classes Our goal here is to get top level definition for all the format variants. Having them defined outside of the function enabled other users of that logic. They are two keys components of a format variant: 1) the name and various descriptions of its effect, 2) the code that checks if the repo is using this variant and if the config enables it. That second items make us pick a class-based approach, since different variants requires different code (even if in practice, many can reuse the same logic). Each variants define its own class that is then used like a singleton. The class-based approach also clarify the definitions part a bit since each are simple assignment in an indented block. The 'fromdefault' and 'fromconfig' are respectively replaced by a class attribute and a method to be called at the one place where "fromconfig" matters. Overall, they are many viable approach for this, but this is the one I picked.

upgrade: introduce a 'formatvariant' class The 'deficiency' type has multiple specificities. We create a dedicated class to host them. More logic will be added incrementally in future changesets.

upgrade: implement '__hash__' on 'improvement' class The pythonomicon request its implementation.

upgrade: implement '__ne__' on 'improvement' class The pythonomicon request its implementation.

color: also enable by default on windows I've not found anything related to color + windows on the bug tracker. So I'm suggesting we get bolder and turn it on for windows too in the release candidate. We can always backout this changeset if we find serious issue on windows.

color: turn on by default (but for windows) Color support is all in core for a couple of months. I've browsed the bug tracker without finding any blocker bug. So I'm moving forward and enable color on by default before '4.2-rc'. In the worse case, having it on in the release candidate will help us to find blocker bug and we can turn it off for the final release. I remember people talking about issue with Windows during the freeze so I'm keeping it off by default on that OS. We could do various cleaning of the color used and the label issued. However the label are probably already in our backward compatibility envelope since the color extensions has been around since for ever and I do not think the color choice themself should be considered BC. So I think we should rather gives color to all user sooner than later. A couple of test needs to be updated to avoid having color related control code spoil the tested output.

pager: stop using the color extension in tests The feature is in core so let us use the core config knob directly.

bundle2: ignore errors seeking a bundle after an exception (issue4784) Many have seen a "stream ended unexpectedly" error. This message is raised from changegroup.readexactly() when a read(n) operation fails to return exactly N bytes. I believe most occurrences of this error in the wild stem from the code changed in this patch. Before, if bundle2's part applicator raised an Exception when processing/applying parts, the exception handler would attempt to iterate the remaining parts. If I/O during this iteration failed, it would likely raise the "stream ended unexpectedly" exception. The problem with this approach is that if we already encountered an I/O error iterating the bundle2 data during application, then any further I/O would almost certainly fail. If the original stream were closed, changegroup.readexactly() would obtain an empty string, triggering "stream ended unexpectedly" with "got 0." This is the error message that users would see. What's worse is that the original I/O related exception would be lost since a new exception would be raised. This made debugging the actual I/O failure effectively impossible. This patch changes the exception handler for bundle2 application to ignore errors when seeking the underlying stream. When the underlying error is I/O related, the seek should fail fast and the original exception will be re-raised. The output changes in test-http-bad-server.t demonstrate this. When the underlying error is not I/O related and the stream can be seeked, the old behavior is preserved.

error: rename RichIOError to PeerTransportError This is a more descriptive name. RichIOError was introduced just hours ago, so it doesn't need to be marked as BC.

httppeer: don't send empty Vary request header As part of writing test-http-bad-server.t, I noticed that some requests include an empty Vary HTTP request header. The Vary HTTP request header indicates which headers should be taken into account when determining if a cached response can be used. It also accepts the special value of "*". The previous code unconditionally added a Vary header. This could lead to an empty header value. While I don't believe this violates the HTTP spec, this is weird and just wastes bytes. So this patch changes behavior to only send a Vary header when it has a value. Some low-level wire protocol byte reporting tests changed. In some cases, the exact point of data termination changed. However, the behavior being tested - that clients react when the connection is closed in the middle of an HTTP request line or header - remains unchanged.