Sat, 15 Apr 2017 11:26:09 +0200 revsetlang: add a getboolean helper function
Denis Laxalde <denis@laxalde.org> [Sat, 15 Apr 2017 11:26:09 +0200] rev 31997
revsetlang: add a getboolean helper function This will be used to parse followlines's "descend" argument.
Tue, 28 Mar 2017 10:15:02 +0200 track-tags: write all tag changes to a file
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 28 Mar 2017 10:15:02 +0200] rev 31996
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.
Tue, 28 Mar 2017 10:14:55 +0200 track-tags: compute the actual differences between tags pre/post transaction
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 28 Mar 2017 10:14:55 +0200] rev 31995
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.
Tue, 28 Mar 2017 06:38:09 +0200 track-tags: introduce first bits of tags tracking during transaction
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 28 Mar 2017 06:38:09 +0200] rev 31994
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.
Tue, 28 Mar 2017 05:06:56 +0200 tags: introduce a function to return a valid fnodes list from revs
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 28 Mar 2017 05:06:56 +0200] rev 31993
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.
Fri, 14 Apr 2017 14:25:06 +0200 context: possibly yield initial fctx in blockdescendants()
Denis Laxalde <denis.laxalde@logilab.fr> [Fri, 14 Apr 2017 14:25:06 +0200] rev 31992
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.
Fri, 14 Apr 2017 14:09:26 +0200 context: add an assertion checking linerange consistency in blockdescendants()
Denis Laxalde <denis.laxalde@logilab.fr> [Fri, 14 Apr 2017 14:09:26 +0200] rev 31991
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.
Fri, 14 Apr 2017 12:34:26 -0700 windows: add win32com.shell to demandimport ignore list
Kostia Balytskyi <ikostia@fb.com> [Fri, 14 Apr 2017 12:34:26 -0700] rev 31990
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
Thu, 13 Apr 2017 16:28:15 +0200 obsolescence: add test for the "branch replacement" logic during push, case D6
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 13 Apr 2017 16:28:15 +0200] rev 31989
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.
Thu, 13 Apr 2017 16:27:54 +0200 obsolescence: add test dor the "branch replacement" logic during push, case D4
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 13 Apr 2017 16:27:54 +0200] rev 31988
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.
Thu, 13 Apr 2017 16:27:42 +0200 obsolescence: add test for the "branch replacement" logic during push, case D2
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 13 Apr 2017 16:27:42 +0200] rev 31987
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.
Thu, 13 Apr 2017 16:27:28 +0200 obsolescence: add test for the "branch replacement" logic during push, case D1
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 13 Apr 2017 16:27:28 +0200] rev 31986
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.
Thu, 13 Apr 2017 16:27:05 +0200 obsolescence: add test for the "branch replacement" logic during push, case C4
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 13 Apr 2017 16:27:05 +0200] rev 31985
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.
Thu, 13 Apr 2017 16:26:51 +0200 obsolescence: add test for the "branch replacement" logic during push, case C3
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 13 Apr 2017 16:26:51 +0200] rev 31984
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.
Thu, 13 Apr 2017 16:26:37 +0200 obsolescence: add test for the "branch replacement" logic during push, case C2
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 13 Apr 2017 16:26:37 +0200] rev 31983
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.
Thu, 13 Apr 2017 16:25:59 +0200 obsolescence: add test for the "branch replacement" logic during push, case B3
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 13 Apr 2017 16:25:59 +0200] rev 31982
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.
Thu, 13 Apr 2017 16:25:44 +0200 obsolescence: add test for the "branch replacement" logic during push, case A8
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 13 Apr 2017 16:25:44 +0200] rev 31981
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.
Thu, 13 Apr 2017 16:25:26 +0200 obsolescence: add test for the "branch replacement" logic during push, case A7
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 13 Apr 2017 16:25:26 +0200] rev 31980
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.
Thu, 13 Apr 2017 16:25:11 +0200 obsolescence: add test for the "branch replacement" logic during push, case A6
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 13 Apr 2017 16:25:11 +0200] rev 31979
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.
Thu, 13 Apr 2017 16:24:57 +0200 obsolescence: add test for the "branch replacement" logic during push, case A5
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 13 Apr 2017 16:24:57 +0200] rev 31978
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.
Thu, 13 Apr 2017 16:23:39 +0200 obsolescence: add test for the "branch replacement" logic during push, case A4
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 13 Apr 2017 16:23:39 +0200] rev 31977
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.
Thu, 13 Apr 2017 16:23:18 +0200 obsolescence: add test for the "branch replacement" logic during push, case A3
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 13 Apr 2017 16:23:18 +0200] rev 31976
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.
Thu, 13 Apr 2017 16:23:01 +0200 obsolescence: add test for the "branch replacement" logic during push, case A2
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 13 Apr 2017 16:23:01 +0200] rev 31975
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.
Thu, 13 Apr 2017 16:22:46 +0200 obsolescence: add test for the "branch replacement" logic during push, case A1
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 13 Apr 2017 16:22:46 +0200] rev 31974
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.
Thu, 13 Apr 2017 16:22:25 +0200 obsolescence: add test utility for the "branch replacement" logic during push
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 13 Apr 2017 16:22:25 +0200] rev 31973
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.
Mon, 10 Apr 2017 16:55:16 +0200 obsolescence: add test case D-4 for obsolescence markers exchange
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 10 Apr 2017 16:55:16 +0200] rev 31972
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
Mon, 10 Apr 2017 16:54:43 +0200 obsolescence: add test case D-3 for obsolescence markers exchange
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 10 Apr 2017 16:54:43 +0200] rev 31971
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
Mon, 10 Apr 2017 16:54:19 +0200 obsolescence: add test case D-2 for obsolescence markers exchange
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 10 Apr 2017 16:54:19 +0200] rev 31970
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
Mon, 10 Apr 2017 16:53:37 +0200 obsolescence: add test case D-1 for obsolescence markers exchange
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 10 Apr 2017 16:53:37 +0200] rev 31969
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
Mon, 10 Apr 2017 16:53:12 +0200 obsolescence: add test case C-4 for obsolescence markers exchange
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 10 Apr 2017 16:53:12 +0200] rev 31968
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
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip