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
Mon, 10 Apr 2017 16:52:25 +0200 obsolescence: add test case C-3 for obsolescence markers exchange
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 10 Apr 2017 16:52:25 +0200] rev 31967
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
Mon, 10 Apr 2017 16:51:06 +0200 obsolescence: add test case C-2 for obsolescence markers exchange
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 10 Apr 2017 16:51:06 +0200] rev 31966
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
Mon, 10 Apr 2017 16:50:41 +0200 obsolescence: add test case C-1 for obsolescence markers exchange
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 10 Apr 2017 16:50:41 +0200] rev 31965
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
Tue, 11 Apr 2017 14:54:12 -0700 stdio: add Linux-specific tests for error checking
Bryan O'Sullivan <bryano@fb.com> [Tue, 11 Apr 2017 14:54:12 -0700] rev 31964
stdio: add Linux-specific tests for error checking
Tue, 11 Apr 2017 14:54:12 -0700 stdio: raise StdioError if something goes wrong in ui.flush
Bryan O'Sullivan <bryano@fb.com> [Tue, 11 Apr 2017 14:54:12 -0700] rev 31963
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.
Tue, 11 Apr 2017 14:54:12 -0700 stdio: raise StdioError if something goes wrong in ui._write_err
Bryan O'Sullivan <bryano@fb.com> [Tue, 11 Apr 2017 14:54:12 -0700] rev 31962
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.
Tue, 11 Apr 2017 14:54:12 -0700 stdio: raise StdioError if something goes wrong in ui._write
Bryan O'Sullivan <bryano@fb.com> [Tue, 11 Apr 2017 14:54:12 -0700] rev 31961
stdio: raise StdioError if something goes wrong in ui._write
Tue, 11 Apr 2017 14:54:12 -0700 stdio: catch StdioError in dispatch.run and clean up appropriately
Bryan O'Sullivan <bryano@fb.com> [Tue, 11 Apr 2017 14:54:12 -0700] rev 31960
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.)
Tue, 11 Apr 2017 14:54:12 -0700 stdio: add machinery to identify failed stdout/stderr writes
Bryan O'Sullivan <bryano@fb.com> [Tue, 11 Apr 2017 14:54:12 -0700] rev 31959
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.
Tue, 11 Apr 2017 14:54:12 -0700 atexit: switch to home-grown implementation
Bryan O'Sullivan <bryano@fb.com> [Tue, 11 Apr 2017 14:54:12 -0700] rev 31958
atexit: switch to home-grown implementation
Tue, 11 Apr 2017 14:54:12 -0700 atexit: test failing handlers
Bryan O'Sullivan <bryano@fb.com> [Tue, 11 Apr 2017 14:54:12 -0700] rev 31957
atexit: test failing handlers
Tue, 11 Apr 2017 14:54:12 -0700 ui: add special-purpose atexit functionality
Bryan O'Sullivan <bryano@fb.com> [Tue, 11 Apr 2017 14:54:12 -0700] rev 31956
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).
Fri, 14 Apr 2017 08:55:18 +0200 context: follow all branches in blockdescendants()
Denis Laxalde <denis@laxalde.org> [Fri, 14 Apr 2017 08:55:18 +0200] rev 31955
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()).
Thu, 13 Apr 2017 08:27:19 -0700 pager: set some environment variables if they're not set
Jun Wu <quark@fb.com> [Thu, 13 Apr 2017 08:27:19 -0700] rev 31954
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
Thu, 13 Apr 2017 14:48:18 -0400 sshpeer: fix docstring typo
Augie Fackler <augie@google.com> [Thu, 13 Apr 2017 14:48:18 -0400] rev 31953
sshpeer: fix docstring typo
Thu, 13 Apr 2017 13:12:49 -0400 util: pass sysstrs to warnings.filterwarnings
Augie Fackler <augie@google.com> [Thu, 13 Apr 2017 13:12:49 -0400] rev 31952
util: pass sysstrs to warnings.filterwarnings Un-breaks the Python 3 build.
Mon, 03 Apr 2017 14:21:38 +0200 vfs: deprecate all old classes in scmutil
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 03 Apr 2017 14:21:38 +0200] rev 31951
vfs: deprecate all old classes in scmutil Now that all vfs class moved to the vfs module, we can deprecate the old one.
Tue, 04 Apr 2017 11:03:29 +0200 util: add a way to issue deprecation warning without a UI object
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 04 Apr 2017 11:03:29 +0200] rev 31950
util: add a way to issue deprecation warning without a UI object Our current deprecation warning mechanism relies on ui object. They are case where we cannot have access to the UI object. On a general basis we avoid using the python mechanism for deprecation warning because up to Python 2.6 it is exposing warning to unsuspecting user who cannot do anything to deal with them. So we build a "safe" strategy to hide this warnings behind a flag in an environment variable. The test runner set this flag so that tests show these warning. This will help us marker API as deprecated for extensions to update their code.
Thu, 13 Apr 2017 09:49:48 +0200 gitweb: plug followlines UI in filerevision view
Denis Laxalde <denis.laxalde@logilab.fr> [Thu, 13 Apr 2017 09:49:48 +0200] rev 31949
gitweb: plug followlines UI in filerevision view Mostly copy CSS rules from style-paper.css into style-gitweb.css. The only modification is addition of !important on "background-color" rule for "pre.sourcelines > span.followlines-selected" selector as the background color is otherwise overriden by "pre.sourcelines.stripes > :nth-child(4n+4)" rule.
Thu, 13 Apr 2017 10:04:09 +0200 gitweb: handle "patch" query parameter in filelog view
Denis Laxalde <denis.laxalde@logilab.fr> [Thu, 13 Apr 2017 10:04:09 +0200] rev 31948
gitweb: handle "patch" query parameter in filelog view As for paper style, in f36dc643ffdc, we display "diff" data as an additional row in the table of revision entries for the gitweb template. Also, as these additional diff rows have a white background, they may be confused with log entry rows ("age", "author", "description", "links") of even parity (parity0 also have a white background). So we disable parity colors for log entry rows when diff is displayed and fix the color to the "dark" parity (i.e. parity1 #f6f6f0) so that it's always distinguishable from
Thu, 13 Apr 2017 09:59:58 +0200 gitweb: add information about "linerange" filtering in filelog view
Denis Laxalde <denis.laxalde@logilab.fr> [Thu, 13 Apr 2017 09:59:58 +0200] rev 31947
gitweb: add information about "linerange" filtering in filelog view As for paper style, in 5e6d44511317, we display a "(following lines <fromline>:<toline> <a href='...'>back to filelog</a>)" message alongside the file name when "linerange" query parameter is present.
Mon, 10 Apr 2017 18:16:30 +0200 util: fix human-readable printing of negative byte counts
Gábor Stefanik <gabor.stefanik@nng.com> [Mon, 10 Apr 2017 18:16:30 +0200] rev 31946
util: fix human-readable printing of negative byte counts Apply the same human-readable printing rules to negative byte counts as to positive ones. Fixes output of debugupgraderepo.
Thu, 13 Apr 2017 03:17:53 -0700 show: make template option actually show up in help
Ryan McElroy <rmcelroy@fb.com> [Thu, 13 Apr 2017 03:17:53 -0700] rev 31945
show: make template option actually show up in help Previously, the --template/-T option didn't show up in help because it's marked as experimental. It's not really experimental for show, and its quite important for show's funcationality, so let's make sure it always shows up.
Wed, 12 Apr 2017 20:31:15 -0700 show: implement underway view
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 12 Apr 2017 20:31:15 -0700] rev 31944
show: implement underway view This is the beginning of a wip/smartlog view. It is basically a manually constructed (read: fast) revset function to collect "relevant" changesets combined with a custom template and a graph displayer. It obviously needs a lot of work. I'd like to get *something* usable in 4.2 so `hg show` has some value to end-users. Let the bikeshedding begin.
Wed, 12 Apr 2017 20:28:44 -0700 show: fix formatting of multiple commands
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 12 Apr 2017 20:28:44 -0700] rev 31943
show: fix formatting of multiple commands Because we're formatting to RST, short lines wrap and there needs to be an extra line break between paragraphs to prevent that. In addition, the indentation in the old code was a bit off. Refactor the code to a function (so we don't leak variables outside the module) and modify it so it renders more correctly.
Wed, 12 Apr 2017 18:42:20 -0700 pycompat: import correct cookie module on Python 3
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 12 Apr 2017 18:42:20 -0700] rev 31942
pycompat: import correct cookie module on Python 3 http.cookielib doesn't exist. http.cookiejar does and it contains the symbols we need. This fixes test failures on Python 3.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip