Thu, 13 Apr 2017 22:31:17 +0900 progress: retry ferr.flush() and .write() on EINTR (issue5532)
Yuya Nishihara <yuya@tcha.org> [Thu, 13 Apr 2017 22:31:17 +0900] rev 32049
progress: retry ferr.flush() and .write() on EINTR (issue5532) See the inline comment how this could mitigate the issue. I couldn't reproduce the exact problem on my Linux machine, but there are at least two people who got EINTR in progress.py, and it seems file_write() of Python 2 is fundamentally broken [1]. Let's make something in on 4.2. [1]: https://hg.python.org/cpython/file/v2.7.13/Objects/fileobject.c#l1850
Thu, 13 Apr 2017 22:27:25 +0900 progress: extract stubs to restart ferr.flush() and .write() on EINTR
Yuya Nishihara <yuya@tcha.org> [Thu, 13 Apr 2017 22:27:25 +0900] rev 32048
progress: extract stubs to restart ferr.flush() and .write() on EINTR
Sat, 25 Feb 2017 19:36:02 +0900 filemerge: optionally strip quotes from merge marker template (BC)
Yuya Nishihara <yuya@tcha.org> [Sat, 25 Feb 2017 19:36:02 +0900] rev 32047
filemerge: optionally strip quotes from merge marker template (BC) For consistency with the other template options. Quotes are necessary if you want to preserve leading/trailing whitespace, which would be stripped by config parser.
Sat, 25 Feb 2017 19:32:39 +0900 commit: optionally strip quotes from commit template (BC)
Yuya Nishihara <yuya@tcha.org> [Sat, 25 Feb 2017 19:32:39 +0900] rev 32046
commit: optionally strip quotes from commit template (BC) For consistency with the other template options.
Sat, 25 Feb 2017 19:28:16 +0900 graphlog: optionally strip quotes from graphnode template (BC)
Yuya Nishihara <yuya@tcha.org> [Sat, 25 Feb 2017 19:28:16 +0900] rev 32045
graphlog: optionally strip quotes from graphnode template (BC) For consistency with the other template options.
Mon, 17 Apr 2017 23:53:19 +0900 dispatch: ignore further SIGPIPE while handling KeyboardInterrupt
Yuya Nishihara <yuya@tcha.org> [Mon, 17 Apr 2017 23:53:19 +0900] rev 32044
dispatch: ignore further SIGPIPE while handling KeyboardInterrupt I got the following error by running "hg log" and quitting the pager immediately. Any output here may trigger another SIGPIPE, so only thing we can do is to swallow the exception and exit with an error status. Traceback (most recent call last): File "./hg", line 45, in <module> mercurial.dispatch.run() File "mercurial/dispatch.py", line 83, in run status = (dispatch(req) or 0) & 255 File "mercurial/dispatch.py", line 167, in dispatch req.ui.warn(_("interrupted!\n")) File "mercurial/ui.py", line 1224, in warn self.write_err(*msg, **opts) File "mercurial/ui.py", line 790, in write_err self._write_err(*msgs, **opts) File "mercurial/ui.py", line 798, in _write_err self.ferr.write(a) File "mercurial/ui.py", line 129, in _catchterm raise error.SignalInterrupt mercurial.error.SignalInterrupt Perhaps this wasn't visible before de5c9d0e02ea because the original stderr handle was restored very late.
Sat, 15 Apr 2017 13:04:55 +0900 worker: print traceback for uncaught exception unconditionally
Yuya Nishihara <yuya@tcha.org> [Sat, 15 Apr 2017 13:04:55 +0900] rev 32043
worker: print traceback for uncaught exception unconditionally This is what a Python interpreter would do if there were no os._exit().
Sat, 15 Apr 2017 13:27:44 +0900 worker: propagate exit code to main process
Yuya Nishihara <yuya@tcha.org> [Sat, 15 Apr 2017 13:27:44 +0900] rev 32042
worker: propagate exit code to main process Follows up 86cd09bc13ba.
Sat, 15 Apr 2017 13:02:34 +0900 dispatch: print traceback in scmutil.callcatch() if --traceback specified
Yuya Nishihara <yuya@tcha.org> [Sat, 15 Apr 2017 13:02:34 +0900] rev 32041
dispatch: print traceback in scmutil.callcatch() if --traceback specified Otherwise, traceback wouldn't be printed for a known exception occurred in worker processes.
Sat, 15 Apr 2017 12:58:06 +0900 dispatch: mark callcatch() as a private function
Yuya Nishihara <yuya@tcha.org> [Sat, 15 Apr 2017 12:58:06 +0900] rev 32040
dispatch: mark callcatch() as a private function
Sat, 15 Apr 2017 10:51:17 +0900 templatefilters: fix crash by string formatting of '{x|splitlines}'
Yuya Nishihara <yuya@tcha.org> [Sat, 15 Apr 2017 10:51:17 +0900] rev 32039
templatefilters: fix crash by string formatting of '{x|splitlines}' Before, it crashed because mapping['templ'] was missing. As it didn't support the legacy list template from the beginning, we can simply use hybridlist().
Wed, 05 Apr 2017 21:57:05 +0900 templatekw: factor out showdict() helper
Yuya Nishihara <yuya@tcha.org> [Wed, 05 Apr 2017 21:57:05 +0900] rev 32038
templatekw: factor out showdict() helper Make it less cryptic for common cases.
Wed, 05 Apr 2017 21:47:34 +0900 templatekw: have showlist() take mapping dict with no **kwargs expansion (API)
Yuya Nishihara <yuya@tcha.org> [Wed, 05 Apr 2017 21:47:34 +0900] rev 32037
templatekw: have showlist() take mapping dict with no **kwargs expansion (API) See the previous commit for why. splitlines() does not pass a mapping dict, which would probably mean the legacy template didn't work from the beginning.
Wed, 05 Apr 2017 21:40:38 +0900 templatekw: change _showlist() to take mapping dict with no **kwargs expansion
Yuya Nishihara <yuya@tcha.org> [Wed, 05 Apr 2017 21:40:38 +0900] rev 32036
templatekw: change _showlist() to take mapping dict with no **kwargs expansion There was a risk that a template keyword could conflict with an argument name (e.g. 'name', 'values', 'plural', etc.) Let's make it less magical.
Wed, 05 Apr 2017 21:32:32 +0900 templatekw: rename 'args' to 'mapping' in showlist()
Yuya Nishihara <yuya@tcha.org> [Wed, 05 Apr 2017 21:32:32 +0900] rev 32035
templatekw: rename 'args' to 'mapping' in showlist() The name 'args' provides no information. Call it 'mapping' as in templater.py.
Wed, 05 Apr 2017 21:27:44 +0900 templatekw: eliminate unnecessary temporary variable 'names' from _showlist()
Yuya Nishihara <yuya@tcha.org> [Wed, 05 Apr 2017 21:27:44 +0900] rev 32034
templatekw: eliminate unnecessary temporary variable 'names' from _showlist() Replace 'names' with the optional argument 'plural'.
Mon, 17 Apr 2017 20:22:00 +0200 color: update the help with the new default
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 17 Apr 2017 20:22:00 +0200] rev 32033
color: update the help with the new default The default is now "auto" we update the help to match reality.
Wed, 12 Apr 2017 16:48:13 +0200 upgrade: register all format variants in a list
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 12 Apr 2017 16:48:13 +0200] rev 32032
upgrade: register all format variants in a list Now that all known format variants exists outside of the function, we can gather them in a lists. This build a single entry point other code can use (current target: extensions). The repository upgrade code is updated to simply use entries from this list. As a side effect this will also allow extensions to register their own format variants, to do this "properly" we should introduce a "registrar" for this category of object. However I prefer to keep this series simple, and that will be adventure for future time.
Wed, 12 Apr 2017 16:34:05 +0200 upgrade: move descriptions and selection logic in individual classes
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 12 Apr 2017 16:34:05 +0200] rev 32031
upgrade: move descriptions and selection logic in individual classes Our goal here is to get top level definition for all the format variants. Having them defined outside of the function enabled other users of that logic. They are two keys components of a format variant: 1) the name and various descriptions of its effect, 2) the code that checks if the repo is using this variant and if the config enables it. That second items make us pick a class-based approach, since different variants requires different code (even if in practice, many can reuse the same logic). Each variants define its own class that is then used like a singleton. The class-based approach also clarify the definitions part a bit since each are simple assignment in an indented block. The 'fromdefault' and 'fromconfig' are respectively replaced by a class attribute and a method to be called at the one place where "fromconfig" matters. Overall, they are many viable approach for this, but this is the one I picked.
Mon, 10 Apr 2017 23:34:43 +0200 upgrade: introduce a 'formatvariant' class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 10 Apr 2017 23:34:43 +0200] rev 32030
upgrade: introduce a 'formatvariant' class The 'deficiency' type has multiple specificities. We create a dedicated class to host them. More logic will be added incrementally in future changesets.
Mon, 17 Apr 2017 13:07:31 +0200 upgrade: implement '__hash__' on 'improvement' class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 17 Apr 2017 13:07:31 +0200] rev 32029
upgrade: implement '__hash__' on 'improvement' class The pythonomicon request its implementation.
Mon, 17 Apr 2017 13:07:22 +0200 upgrade: implement '__ne__' on 'improvement' class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 17 Apr 2017 13:07:22 +0200] rev 32028
upgrade: implement '__ne__' on 'improvement' class The pythonomicon request its implementation.
Sun, 16 Apr 2017 02:34:08 +0200 color: also enable by default on windows
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 16 Apr 2017 02:34:08 +0200] rev 32027
color: also enable by default on windows I've not found anything related to color + windows on the bug tracker. So I'm suggesting we get bolder and turn it on for windows too in the release candidate. We can always backout this changeset if we find serious issue on windows.
Sun, 16 Apr 2017 02:32:51 +0200 color: turn on by default (but for windows)
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 16 Apr 2017 02:32:51 +0200] rev 32026
color: turn on by default (but for windows) Color support is all in core for a couple of months. I've browsed the bug tracker without finding any blocker bug. So I'm moving forward and enable color on by default before '4.2-rc'. In the worse case, having it on in the release candidate will help us to find blocker bug and we can turn it off for the final release. I remember people talking about issue with Windows during the freeze so I'm keeping it off by default on that OS. We could do various cleaning of the color used and the label issued. However the label are probably already in our backward compatibility envelope since the color extensions has been around since for ever and I do not think the color choice themself should be considered BC. So I think we should rather gives color to all user sooner than later. A couple of test needs to be updated to avoid having color related control code spoil the tested output.
Sun, 16 Apr 2017 02:48:06 +0200 pager: stop using the color extension in tests
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 16 Apr 2017 02:48:06 +0200] rev 32025
pager: stop using the color extension in tests The feature is in core so let us use the core config knob directly.
Sun, 16 Apr 2017 11:55:08 -0700 bundle2: ignore errors seeking a bundle after an exception (issue4784)
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 16 Apr 2017 11:55:08 -0700] rev 32024
bundle2: ignore errors seeking a bundle after an exception (issue4784) Many have seen a "stream ended unexpectedly" error. This message is raised from changegroup.readexactly() when a read(n) operation fails to return exactly N bytes. I believe most occurrences of this error in the wild stem from the code changed in this patch. Before, if bundle2's part applicator raised an Exception when processing/applying parts, the exception handler would attempt to iterate the remaining parts. If I/O during this iteration failed, it would likely raise the "stream ended unexpectedly" exception. The problem with this approach is that if we already encountered an I/O error iterating the bundle2 data during application, then any further I/O would almost certainly fail. If the original stream were closed, changegroup.readexactly() would obtain an empty string, triggering "stream ended unexpectedly" with "got 0." This is the error message that users would see. What's worse is that the original I/O related exception would be lost since a new exception would be raised. This made debugging the actual I/O failure effectively impossible. This patch changes the exception handler for bundle2 application to ignore errors when seeking the underlying stream. When the underlying error is I/O related, the seek should fail fast and the original exception will be re-raised. The output changes in test-http-bad-server.t demonstrate this. When the underlying error is not I/O related and the stream can be seeked, the old behavior is preserved.
Sun, 16 Apr 2017 11:12:37 -0700 error: rename RichIOError to PeerTransportError
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 16 Apr 2017 11:12:37 -0700] rev 32023
error: rename RichIOError to PeerTransportError This is a more descriptive name. RichIOError was introduced just hours ago, so it doesn't need to be marked as BC.
Sun, 16 Apr 2017 11:28:02 -0700 httppeer: don't send empty Vary request header
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 16 Apr 2017 11:28:02 -0700] rev 32022
httppeer: don't send empty Vary request header As part of writing test-http-bad-server.t, I noticed that some requests include an empty Vary HTTP request header. The Vary HTTP request header indicates which headers should be taken into account when determining if a cached response can be used. It also accepts the special value of "*". The previous code unconditionally added a Vary header. This could lead to an empty header value. While I don't believe this violates the HTTP spec, this is weird and just wastes bytes. So this patch changes behavior to only send a Vary header when it has a value. Some low-level wire protocol byte reporting tests changed. In some cases, the exact point of data termination changed. However, the behavior being tested - that clients react when the connection is closed in the middle of an HTTP request line or header - remains unchanged.
Sun, 16 Apr 2017 21:25:16 -0400 badserverext: explicitly flush each log write
Matt Harbison <matt_harbison@yahoo.com> [Sun, 16 Apr 2017 21:25:16 -0400] rev 32021
badserverext: explicitly flush each log write No idea why, but without this, there was no content in the error logs that are `cat`d in the test on Windows.
Sun, 16 Apr 2017 21:00:22 -0400 test-http-bad-server: conditionalize error output for Windows
Matt Harbison <matt_harbison@yahoo.com> [Sun, 16 Apr 2017 21:00:22 -0400] rev 32020
test-http-bad-server: conditionalize error output for Windows
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip