Fri, 26 Aug 2011 16:07:16 -0500 Added signature for changeset d629f1e89021 stable
Matt Mackall <mpm@selenic.com> [Fri, 26 Aug 2011 16:07:16 -0500] rev 15060
Added signature for changeset d629f1e89021
Fri, 26 Aug 2011 16:07:13 -0500 Added tag 1.9.2 for changeset d629f1e89021 stable
Matt Mackall <mpm@selenic.com> [Fri, 26 Aug 2011 16:07:13 -0500] rev 15059
Added tag 1.9.2 for changeset d629f1e89021
Thu, 25 Aug 2011 11:03:16 +0200 util: postpone and reorder parent calculation in makedirs
Adrian Buehlmann <adrian@cadifra.com> [Thu, 25 Aug 2011 11:03:16 +0200] rev 15058
util: postpone and reorder parent calculation in makedirs
Thu, 25 Aug 2011 20:21:04 -0400 atomictempfile: make close() consistent with other file-like objects.
Greg Ward <greg@gerg.ca> [Thu, 25 Aug 2011 20:21:04 -0400] rev 15057
atomictempfile: make close() consistent with other file-like objects. The usual contract is that close() makes your writes permanent, so atomictempfile's use of close() to *discard* writes (and rename() to keep them) is rather unexpected. Thus, change it so close() makes things permanent and add a new discard() method to throw them away. discard() is only used internally, in __del__(), to ensure that writes are discarded when an atomictempfile object goes out of scope. I audited mercurial.*, hgext.*, and ~80 third-party extensions, and found no one using the existing semantics of close() to discard writes, so this should be safe.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip