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.
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.
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.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
This changeset adds test for the improved "branch replacement" logic introduce
in an earlier commits. This tests initially lived in the evolve extensions.
Since we now have the code handling this logic in core, it make sense to have
the tests in core too.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
This changeset adds test for the improved "branch replacement" logic introduce
in an earlier commits. This tests initially lived in the evolve extensions.
Since we now have the code handling this logic in core, it make sense to have
the tests in core too.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
This changeset adds test for the improved "branch replacement" logic introduce
in an earlier commits. This tests initially lived in the evolve extensions.
Since we now have the code handling this logic in core, it make sense to have
the tests in core too.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
This changeset adds test for the improved "branch replacement" logic introduce
in an earlier commits. This tests initially lived in the evolve extensions.
Since we now have the code handling this logic in core, it make sense to have
the tests in core too.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
This changeset adds test for the improved "branch replacement" logic introduce
in an earlier commits. This tests initially lived in the evolve extensions.
Since we now have the code handling this logic in core, it make sense to have
the tests in core too.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
This changeset adds test for the improved "branch replacement" logic introduce
in an earlier commits. This tests initially lived in the evolve extensions.
Since we now have the code handling this logic in core, it make sense to have
the tests in core too.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
This changeset adds test for the improved "branch replacement" logic introduce
in an earlier commits. This tests initially lived in the evolve extensions.
Since we now have the code handling this logic in core, it make sense to have
the tests in core too.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
This changeset adds test for the improved "branch replacement" logic introduce
in an earlier commits. This tests initially lived in the evolve extensions.
Since we now have the code handling this logic in core, it make sense to have
the tests in core too.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
This changeset adds test for the improved "branch replacement" logic introduce
in an earlier commits. This tests initially lived in the evolve extensions.
Since we now have the code handling this logic in core, it make sense to have
the tests in core too.
See inline documentation for details about the test case added in this
changeset.
The previous logic had many shortcoming (eg: looking at the head only, not
handling prune, etc...), the new logic use a more robust approach:
For each head, we check if after the push all changesets exclusive to this heads
will be obsolete. If they are, the branch considered be "replaced".
To check if a changeset will be obsolete, we simply checks:
* the changeset phase
* the existence of a marker relevant to the "pushed set" that affects the
changesets..
This fixes two major issues of the previous algorithm:
* branch partially rewritten (eg: head but not root) are no longer detected as
replaced,
* Prune are now properly handled.
(This implementation was introduction in the evolve extension, version 6.0.0.)
This new algorithm has an extended number of tests, a basic one is provided
in this patch. The others will be introduced in their own changeset for clarity.
In addition, we stop trying to process heads unknown locally, we do not have
enough data to take an informed decision so we should stop pretending we do.
This reflect a test that is now update.
Cramming all of this directly into an alias doesn't play nicely on Windows.
Various test-exchange-obsmarkers-case-XX.t were failing with:
abort: cannot select revision when creating marker
It turned out that inside debugcommands.debugobsolete(), the following differed
from Linux (where they were empty, at least in the case I debugged):
'rev': ['.`;'],
'template': "'{node}\\n'"
I've been using `hg serve --web-conf ...` with a simple '/=projects/**' [paths]
configuration for awhile without issue. Let's ditch the need for the manual
configuration in this case, and limit the repos served to the actual subrepos.
This doesn't attempt to handle the case where a new subrepo appears while the
server is running. That could probably be handled with a hook if somebody wants
it. But it's such a rare case, it probably doesn't matter for the temporary
serves.
The main repo is served at '/', just like a repository without subrepos. I'm
not sure why the duplicate 'adding ...' lines appear on Linux. They don't
appear on Windows (see 3f4ff1bdf101), so they are optional.
Subrepositories that are configured with '../path' or absolute paths are not
cloneable from the server. (They aren't cloneable locally either, unless they
also exist at their configured source, perhaps via the share extension.) They
are still served, so that they can be browsed, or cloned individually. If we
care about that cloning someday, we can probably just add the extra entries to
the webconf dictionary. Even if the entries use '../' to escape the root, only
the related subrepositories would end up in the dictionary.
Now that the response instance itself is wrapped with error
handling, we no longer need this code. This code became dead
with the previous patch because the added code catches
HTTPException and re-raises as something else.
There were a handful of places in the code where HTTPResponse.read()
was called with no explicit error handling or with inconsistent
error handling. In order to eliminate this class of bug, we globally
swap out HTTPResponse.read() with a unified error handler.
I initially attempted to fix all call sites. However, after
going down that rabbit hole, I figured it was best to just change
read() to do what we want. This appears to be a worthwhile
change, as the tests demonstrate many of our uncaught exceptions
go away.
To better represent this class of failure, we introduce a new
error type. The main benefit over IOError is it can hold a hint.
I'm receptive to tweaking its name or inheritance.
I've spent several hours over the past few weeks investigating
networking failures involving hg.mozilla.org. As part of this, it
has become clear that the Mercurial client's error handling when
it encounters network failures is far from robust.
To prove this is true, I've devised a battery of tests simulating
various network failures, notably premature connection closes. To
achieve this, I've implemented an extension that monkeypatches the
built-in HTTP server and hooks in at the socket level and allows
various events to occur based on config options. For example, you
can refuse to accept() a client socket or you can close() the socket
after N bytes have been sent or received. The latter effectively
simulates an unexpected connection drop (and these occur all the
time in the real world).
The new test file launches servers exhibiting various "bad" behaviors
and points a client at them. As the many TODO comments in the test
call attention to, Mercurial often displays unhelpful errors when
network-related failures occur. This makes it difficult for users
to understand what's going on and difficult for server administrators
to pinpoint root causes without packet tracing.
Upcoming patches will attempt to fix these error handling
deficiencies.
An upcoming patch will add low-level testing of the bytes being sent
over the wire. As part of developing that test, I discovered that the
order of headers in HTTP requests wasn't deterministic. This patch
makes the order deterministic to make things easier to test.
We parse "descend" symbol as a Boolean using getboolean (prior extraction by
getargsdict already checked that it is a symbol).
In tests, check for error cases and vary Boolean values here and there.
The tag changes information we compute is now written to disk. This gives
hooks full access to that data.
The format picked for that file uses a 2 characters prefix for the action:
-R: tag removed
+A: tag added
-M: tag moved (old value)
+M: tag moved (new value)
This format allows hooks to easily select the line that matters to them without
having to post process the file too much. Here is a couple of examples:
* to select all newly tagged changeset, match "^+",
* to detect tag move, match "^.M",
* to detect tag deletion, match "-R".
Once again we rely on the fact the tag tests run through all possible
situations to test this change.
We now compute the proper actuall differences between tags before and after the
transaction. This catch a couple of false positives in the tests.
The compute the full difference since we are about to make this data available
to hooks in the next changeset.
This changeset introduces detection of tags changes during transaction. When
this happens a 'tag_moved=1' argument is set for hooks, similar to what we do
for bookmarks and phases.
This code is disabled by default as there are still various performance
concerns. Some require a smarter use of our existing tag caches and some other
require rework around the transaction logic to skip execution when unneeded.
These performance improvements have been delayed, I would like to be able to
experiment and stabilize the feature behavior first.
Later changesets will push the concept further and provide a way for hooks to
know what are the actual changes introduced by the transaction. Similar work
is needed for the other families of changes (bookmark, phase, obsolescence,
etc). Upgrade of the transaction logic will likely be performed at the same
time.
The current code can report some false positive when .hgtags file changes but
resulting tags are unchanged. This will be fixed in the next changeset.
For testing, we simply globally enable a hook in the tag test as all the
possible tag update cases should exist there. A couple of them show the false
positive mentioned above.
See in code documentation for more details.
This will get used to compare tags between two set of revisions during a
transaction (pre and post heads). The end goal is to be able to track tags
movement in transaction hooks.
If initial 'fctx' has changes in line range with respect to its parents, we
yield it first. This makes 'followlines(..., descend=True)' consistent with
'descendants()' revset which yields the starting revision.
We reuse one iteration of blockancestors() which does exactly what we want.
In test-annotate.t, adjust 'startrev' in one case to cover the situation where
the starting revision does not touch specified line range.
If this assertion fails, this indicates a flaw in the algorithm. So fail fast
instead of possibly producing wrong results.
Also extend the target line range in test to catch a merge changeset with all
its parents.
Module 'appdirs' tries to import win32com.shell (and catch ImportError as an
indication of failure) to check whether some further functionality should
be implemented one or another way [1]. Of course, demandimport lets it down, so
if we want appdirs to work we have to add it to demandimport's ignore list.
The reason we want appdirs to work is becuase it is used by setuptools [2] to
determine egg cache location. Only fairly recent versions of setuptools depend
on this so people don't see this often.
[1] https://github.com/ActiveState/appdirs/blob/master/appdirs.py#L560
[2] aae0a92811/pkg_resources/__init__.py (L1369)
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.
See inline documentation for details about the test case added in this
changeset.
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.
See inline documentation for details about the test case added in this
changeset.
