obsolescence: add test for the "branch replacement" logic during push, case B6 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.

obsolescence: add test for the "branch replacement" logic during push, case B5 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.

obsolescence: add test for the "branch replacement" logic during push, case B4 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.

obsolescence: add test for the "branch replacement" logic during push, case B2 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.

checkheads: upgrade the obsolescence postprocessing logic (issue4354) 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.

test-http: add a (glob) for Windows I'm not sure why the glob was ineffective with $TESTTMP here, but replacing it with '*' works.

testlib: move the prune alias into a shell script for Windows 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'"

hidden: extract the code generating "filtered rev" error for wrapping The goal is to help experimentation in extensions (ie: evolve) around more advance messages.

serve: add support for Mercurial subrepositories 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 594dd384803c), 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.

hgwebdir: allow a repository to be hosted at "/" This can be useful in general, but will also be useful for hosting subrepos, with the main repo at /.

httppeer: eliminate decompressresponse() proxy 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.

httppeer: wrap HTTPResponse.read() globally 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.

tests: add tests for poorly behaving HTTP server 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.

phases: emit phases to pushkey protocol in deterministic order An upcoming test will report exact bytes sent over the wire protocol. Without this change, the ordering of phases listkey data is non-deterministic.

keepalive: send HTTP request headers in a deterministic order 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.

revset: properly parse "descend" argument of followlines() 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.

revsetlang: add a getboolean helper function This will be used to parse followlines's "descend" argument.

track-tags: write all tag changes to a file 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.

track-tags: compute the actual differences between tags pre/post transaction 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.

track-tags: introduce first bits of tags tracking during transaction 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.

tags: introduce a function to return a valid fnodes list from revs 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.

context: possibly yield initial fctx in blockdescendants() 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.

context: add an assertion checking linerange consistency in blockdescendants() 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.

windows: add win32com.shell to demandimport ignore list 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] https://github.com/pypa/setuptools/blob/aae0a928119d2a178882c32bded02270e30d0273/pkg_resources/__init__.py#L1369

obsolescence: add test for the "branch replacement" logic during push, case D6 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.

obsolescence: add test dor the "branch replacement" logic during push, case D4 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.

obsolescence: add test for the "branch replacement" logic during push, case D2 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.

obsolescence: add test for the "branch replacement" logic during push, case D1 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.

obsolescence: add test for the "branch replacement" logic during push, case C4 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.

obsolescence: add test for the "branch replacement" logic during push, case C3 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.

obsolescence: add test for the "branch replacement" logic during push, case C2 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.

obsolescence: add test for the "branch replacement" logic during push, case B3 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.

obsolescence: add test for the "branch replacement" logic during push, case A8 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.

obsolescence: add test for the "branch replacement" logic during push, case A7 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.

obsolescence: add test for the "branch replacement" logic during push, case A6 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.

obsolescence: add test for the "branch replacement" logic during push, case A5 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.

obsolescence: add test for the "branch replacement" logic during push, case A4 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.

obsolescence: add test for the "branch replacement" logic during push, case A3 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 case. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case A2 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 case. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case A1 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 case. See inline documentation for details about the test case added in this changeset.

obsolescence: add test utility for the "branch replacement" logic during push 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 case. This changeset introduce the common setup script used by these tests.

obsolescence: add test case D-4 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case D-4: unknown changeset in between known on Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case D-3 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case D3: missing prune target (prune not in "pushed set") Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case D-2 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce D-2: missing prune target (prune in "pushed set") Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case D-1 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case D-1: Pruned changeset based on missing precursor of something not present Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case C-4 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce C.4: multiple successors, one is pruned Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case C-3 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case C-3: Pruned changeset on precursors of another pruned one Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case C-2 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce C-2: Pruned changeset on precursors Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case C-1 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce C-1: Multiple pruned changeset atop each other Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

stdio: add Linux-specific tests for error checking

stdio: raise StdioError if something goes wrong in ui.flush The prior code used to ignore all errors, which was intended to deal with a decade-old problem with writing to broken pipes on Windows. However, that code inadvertantly went a lot further, making it impossible to detect *all* I/O errors on stdio ... but only sometimes. What actually happened was that if Mercurial wrote less than a stdio buffer's worth of output (the overwhelmingly common case for most commands), any error that occurred would get swallowed here. But if the buffering strategy changed, an unhandled IOError could be raised from any number of other locations. Because we now have a top-level StdioError handler, and ui._write and ui._write_err (and now flush!) will raise that exception, we have one rational place to detect and handle these errors.

stdio: raise StdioError if something goes wrong in ui._write_err The prior code used to ignore certain classes of error, which was not the right thing to do.

stdio: raise StdioError if something goes wrong in ui._write

stdio: catch StdioError in dispatch.run and clean up appropriately We attempt to report what went wrong, and more importantly exit the program with an error code. (The exception we catch is not yet raised anywhere in the code.)

stdio: add machinery to identify failed stdout/stderr writes Mercurial currently fails to notice failures to write to stdout or stderr. A correctly functioning command line tool should detect this and exit with an error code. To achieve this, we need a little extra plumbing, which we start adding here.

atexit: switch to home-grown implementation

atexit: test failing handlers

ui: add special-purpose atexit functionality In spite of its longstanding use, Python's built-in atexit code is not suitable for Mercurial's purposes, for several reasons: * Handlers run after application code has finished. * Because of this, the code that runs handlers swallows exceptions (since there's no possible stacktrace to associate errors with). If we're lucky, we'll get something spat out to stderr (if stderr still works), which of course isn't any use in a big deployment where it's important that exceptions get logged and aggregated. * Mercurial's current atexit handlers make unfortunate assumptions about process state (specifically stdio) that, coupled with the above problems, make it impossible to deal with certain categories of error (try "hg status > /dev/full" on a Linux box). * In Python 3, the atexit implementation is completely hidden, so we can't hijack the platform's atexit code to run handlers at a time of our choosing. As a result, here's a perfectly cromulent atexit-like implementation over which we have control. This lets us decide exactly when the handlers run (after each request has completed), and control what the process state is when that occurs (and afterwards).

context: follow all branches in blockdescendants() In the initial implementation of blockdescendants (and thus followlines(..., descend=True) revset), only the first branch encountered in descending direction was followed. Update the algorithm so that all children of a revision ('x' in code) are considered. Accordingly, we need to prevent a child revision to be yielded multiple times when it gets visited through different path, so we skip 'i' when this occurs. Finally, since we now consider all parents of a possible child touching a given line range, we take care of yielding the child if it has a diff in specified line range with at least one of its parent (same logic as blockancestors()).

pager: set some environment variables if they're not set Git did this already [1] [2]. We want this behavior too [3]. This provides a better default user experience (like, supporting colors) if users have things like "PAGER=less" set, which is not uncommon. The environment variables are provided by a method so extensions can override them on demand. [1]: https://github.com/git/git/blob/6a5ff7acb5965718cc7016c0ab6c601454fd7cde/pager.c#L87 [2]: https://github.com/git/git/blob/6a5ff7acb5965718cc7016c0ab6c601454fd7cde/Makefile#L1545 [3]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-March/094780.html