Fri, 06 Feb 2015 16:15:02 -0800 run-tests: avoid printing extra newlines from install log
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 16:15:02 -0800] rev 24074
run-tests: avoid printing extra newlines from install log If an installation error occurs, we print the install log. Before, output had extra newlines because we were using "print" on data that was already newline terminated.
Fri, 06 Feb 2015 11:27:25 -0800 bundlerepo: basic bundle2 support
Eric Sumner <ericsumner@fb.com> [Fri, 06 Feb 2015 11:27:25 -0800] rev 24073
bundlerepo: basic bundle2 support For bundlerepo to work with bundle2 files, we need to find the part that contains the bundle's changegroup data and work with that instead of the entire bundle. Future work can add separate processing for other bundle2 parts.
Thu, 05 Feb 2015 16:03:26 -0800 bundlerepo: keep track of the original bundle object
Eric Sumner <ericsumner@fb.com> [Thu, 05 Feb 2015 16:03:26 -0800] rev 24072
bundlerepo: keep track of the original bundle object Bundlerepo should always close() the object that it receives from exchange.readbundle(). When bundle2 support is added in a later diff, self.bundle will be overwritten to be the changegroup part instead of the entire bundle unpacker.
Thu, 05 Feb 2015 15:56:50 -0800 bundle2.unbundle20: add compressed() method
Eric Sumner <ericsumner@fb.com> [Thu, 05 Feb 2015 15:56:50 -0800] rev 24071
bundle2.unbundle20: add compressed() method Bundlerepo uses the compressed() method to determine whether it should write an uncompressed temporary file. Since we don't support compressed bundle2 files at the moment, make this method return true.
Thu, 05 Feb 2015 15:52:57 -0800 bundle2.unpackermixin: default value for seek() whence parameter
Eric Sumner <ericsumner@fb.com> [Thu, 05 Feb 2015 15:52:57 -0800] rev 24070
bundle2.unpackermixin: default value for seek() whence parameter The contract for seek() includes seeking to an offset from the beginning of the file when whence is omitted; put this implementation in compliance.
Fri, 06 Feb 2015 23:40:46 +0100 windows: adjust doc string and comments of posixfile()
Adrian Buehlmann <adrian@cadifra.com> [Fri, 06 Feb 2015 23:40:46 +0100] rev 24069
windows: adjust doc string and comments of posixfile() The doc string of osutil.posixfile includes (line 611): "On error, this function may raise either a WindowsError or an IOError." which is most likely correct, but does not fit for this function here anymore, as we do fold WindowsError to IOError here specifically. And this function is now a bit more than just an exception-wrapper, as it has been expanded to additionally sanitize the unloved seek/tell behavior of Windows. (Self-disclosure: This patch is entirely untested at the time of its publication, as I'm currently not using this version myself. I send it in hopes that it will reduce potential future confusion. CC-ing Matt Harbison)
Wed, 04 Feb 2015 14:11:45 -0800 color: support a different color mode when the pager is active
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 04 Feb 2015 14:11:45 -0800] rev 24068
color: support a different color mode when the pager is active MSYS on Windows has a terminal that supports the "win32" color mode (which "auto" properly detects for us). However, a popularily configured pager in that environment (GNU less) only supports the "ansi" color mode. This patch teaches color about a new config option: pagermode. It behaves like "mode" but is only consulted when the pager is active for the current command. MSYS users can now set "pagermode = ansi" and get a colorful experience that just works. Previously, MSYS users would have to live without color when using GNU less as the pager, would have to manually configure the pager to attend every command, or would have gibberish if "ansi" was used without the pager.
Fri, 06 Feb 2015 12:09:09 -0800 pager: ensure wrapped dispatch._runcommand runs before color's
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 12:09:09 -0800] rev 24067
pager: ensure wrapped dispatch._runcommand runs before color's An upcoming patch will teach color to potentially act differently if the pager is active. Since both extensions wrap the same function (dispatch._runcommand) to change behavior, we must guarantee that pager's wrapped function runs before color's so color may read the breadcrumb left by pager.
Fri, 06 Feb 2015 12:07:56 -0800 pager: set an attribute on ui indicating that a pager is active
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 12:07:56 -0800] rev 24066
pager: set an attribute on ui indicating that a pager is active A subsequent patch will teach the color extension to do different things depending on whether a pager is active. This patch leaves a breadcrumb on the ui instance to allow it do that that.
Fri, 06 Feb 2015 12:07:32 -0800 extensions: support callbacks after another extension loads
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 12:07:32 -0800] rev 24065
extensions: support callbacks after another extension loads An upcoming patch will introduce a dependency between the color and pager extensions. To prepare for this, we teach extensions how to register callbacks that can execute when another extension loads. This patch is based on code provided by Matt Mackall. But significant parts have changed (such as the ability to register multiple callbacks and the change in behavior to always call a callback). I believe that always firing the callback is a good practice. I think the common use for this feature will be for extensions to say "run this one-time setup code, after this other extension if possible." Always running the callback will facilitate this.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip