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()).
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 tip