Mon, 25 Apr 2011 13:03:26 +0300 check-code: separate warnings to avoid repetitive str.startswith
Idan Kamara <idankk86@gmail.com> [Mon, 25 Apr 2011 13:03:26 +0300] rev 14009
check-code: separate warnings to avoid repetitive str.startswith
Sun, 24 Apr 2011 17:30:50 -0400 atomictempfile: rewrite docstring to clarify rename() vs. close().
Greg Ward <greg@gerg.ca> [Sun, 24 Apr 2011 17:30:50 -0400] rev 14008
atomictempfile: rewrite docstring to clarify rename() vs. close().
Sun, 24 Apr 2011 19:25:10 -0400 atomictempfile: avoid infinite recursion in __del__().
Greg Ward <greg@gerg.ca> [Sun, 24 Apr 2011 19:25:10 -0400] rev 14007
atomictempfile: avoid infinite recursion in __del__(). The problem is that a programmer using atomictempfile directly can make an innocent everyday mistake -- not enough args to the constructor -- which escalates badly. You would expect a simple TypeError crash in that case, but you actually get an infinite recursion that is surprisingly difficult to kill: it happens between __del__() and __getattr__(), and Python does not handle infinite recursion from __del__() well. The fix is to not implement __getattr__(), but instead assign instance attributes for the methods we wish to delegate to the builtin file type: write() and fileno(). I've audited mercurial.* and hgext.* and found no users of atomictempfile using methods other than write() and rename(). I audited third-party extensions and found one (snap) passing an atomictempfile to util.fstat(), so I also threw in fileno(). The last time I submitted a similar patch, Matt proposed that we make atomictempfile a subclass of file instead of wrapping it. Rejected on grounds of unnecessary complexity: for one thing, it would make the Windows implementation of posixfile quite a bit more complex. It would have to become a subclass of file rather than a simple function -- but since it's written in C, this is non-obvious and non-trivial. Furthermore, there's nothing wrong with wrapping objects and delegating methods: it's a well-established pattern that works just fine in many cases. Subclassing is not the answer to all of life's problems.
Mon, 25 Apr 2011 18:42:31 +0200 run-tests: display diff before prompting with --interactive
Patrick Mezard <pmezard@gmail.com> [Mon, 25 Apr 2011 18:42:31 +0200] rev 14006
run-tests: display diff before prompting with --interactive
Sat, 23 Apr 2011 00:52:21 +0300 check-code: warn about naked except clauses
Idan Kamara <idankk86@gmail.com> [Sat, 23 Apr 2011 00:52:21 +0300] rev 14005
check-code: warn about naked except clauses
Sat, 23 Apr 2011 00:51:25 +0300 eliminate various naked except clauses
Idan Kamara <idankk86@gmail.com> [Sat, 23 Apr 2011 00:51:25 +0300] rev 14004
eliminate various naked except clauses
Sun, 24 Apr 2011 17:52:46 -0500 run-tests: fix some missing i/o locks
Matt Mackall <mpm@selenic.com> [Sun, 24 Apr 2011 17:52:46 -0500] rev 14003
run-tests: fix some missing i/o locks
Sun, 24 Apr 2011 16:46:37 -0500 run-tests: add a lock for console I/O
Matt Mackall <mpm@selenic.com> [Sun, 24 Apr 2011 16:46:37 -0500] rev 14002
run-tests: add a lock for console I/O
Sun, 24 Apr 2011 16:42:15 -0500 run-tests: switch timeout handling from alarm to helper thread
Matt Mackall <mpm@selenic.com> [Sun, 24 Apr 2011 16:42:15 -0500] rev 14001
run-tests: switch timeout handling from alarm to helper thread This should be slightly more portable than signals and be compatible with threaded dispatch.
Sun, 24 Apr 2011 16:42:11 -0500 run-tests: add locking on results struct
Matt Mackall <mpm@selenic.com> [Sun, 24 Apr 2011 16:42:11 -0500] rev 14000
run-tests: add locking on results struct
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip