hg-stable: Changelog

tests: add script to disable a selected wire protocol capability This can be used to test that the client and server both fall back to the previous wire protocol when the capability is not supported. It is currently used by test-push-http.t and I plan to use it for the HTTP long argument support tests.

mq: prevent traceback when qfinish patches not in series. When mq status entry referencing a patches that is not in series `hg qfinish -a` used to issue a traceback. This states is inconsistent but might happen regularly when people misuse hg up -mq. This changeset prevent hg from crashing. The faulty entry is finished anyway and a warning is issued.

check-code: separate warnings to avoid repetitive str.startswith

atomictempfile: rewrite docstring to clarify rename() vs. close().

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.