Fri, 24 Apr 2015 15:29:02 -0500 merge with i18n stable
Matt Mackall <mpm@selenic.com> [Fri, 24 Apr 2015 15:29:02 -0500] rev 24855
merge with i18n
Thu, 23 Apr 2015 00:07:37 -0300 i18n-pt_BR: synchronized with 5947a68fa271 stable
Wagner Bruna <wbruna@yahoo.com> [Thu, 23 Apr 2015 00:07:37 -0300] rev 24854
i18n-pt_BR: synchronized with 5947a68fa271
Fri, 24 Apr 2015 14:52:12 -0400 template-phases: do not show description or summary if empty stable
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 24 Apr 2015 14:52:12 -0400] rev 24853
template-phases: do not show description or summary if empty This is a copy of c1cb6523e968, but applied to the phases template, which is itself almost a copy of the default template. Perhaps we should rewrite these templates to use the %include syntax afforded by config files. This change seems a bit too big for stable, though.
Fri, 24 Apr 2015 14:17:14 -0400 test-command-template: add a short description of a temporary snippet stable
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 24 Apr 2015 14:17:14 -0400] rev 24852
test-command-template: add a short description of a temporary snippet This snippet was introduced by c1cb6523e968. Its purpose seems a bit obscure without historical context.
Thu, 23 Apr 2015 16:36:18 +0100 bundle2: also save output when error happens during part processing stable
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 23 Apr 2015 16:36:18 +0100] rev 24851
bundle2: also save output when error happens during part processing Until this changeset, we were only able to save output if an error happened during the 'transaction.close()' phase. If the 'processbundle' call raised an exception, the 'bundleoperation' object was never returned, so the reply bundle was never accessible and no output could be salvaged. We introduce a quick (but not very elegant) fix to gain access to any reply created during the processing. This conclude this output related series. We should hopefully be able client-side to see the whole server output, in a proper order. The code is now complex enough that a refactoring of it would make sense on default.
Thu, 23 Apr 2015 14:54:45 +0100 bundle2: capture output issue during transaction close stable
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 23 Apr 2015 14:54:45 +0100] rev 24850
bundle2: capture output issue during transaction close We were capturing all output issue during bundle2 processing, and all output issue during transaction rollback in case of failure. However, the output issue during transaction commit was still roaming the land freely. It is now put back in line. This let the user see output from 'pretxnclose' and 'txnclose' (and related) in the right order.
Thu, 23 Apr 2015 17:03:58 +0100 bundle2: also capture hook output during processing stable
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 23 Apr 2015 17:03:58 +0100] rev 24849
bundle2: also capture hook output during processing External hook used to directly write on stdout and stderr. As a result their output was not captured by the bundle2 processing. This resulted in confusing out of order output on the client side. We are now capturing hooks output in this context.
Thu, 23 Apr 2015 14:57:39 +0100 ui: allow capture of subprocess output stable
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 23 Apr 2015 14:57:39 +0100] rev 24848
ui: allow capture of subprocess output We want to capture hooks output during bundle2 processing. For this purpose we introduce a new 'subproc' argument to 'ui.pushbuffer'. When set, the output of sub process created through 'ui.system' will be captured in the buffer too. This will be used in the next changeset.
Thu, 23 Apr 2015 14:20:36 +0100 bundle2: capture transaction rollback message output (issue4614) stable
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 23 Apr 2015 14:20:36 +0100] rev 24847
bundle2: capture transaction rollback message output (issue4614) The output from the transaction rollback was not included into the reply bundle. It was eventually caught by the usual 'unbundle' output capture and sent to the client but the result was out of order on the client side. We now capture the output for the transaction release and transmit it the same way as all other output. We should probably rethink the whole output capture things but this would not be appropriate for stable. The is still multiple cases were output failed to be properly capture, they will be fixed in later changesets.
Fri, 24 Apr 2015 00:46:48 +0100 bundle2: issue remote output as "status" (issue4612) stable
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 24 Apr 2015 00:46:48 +0100] rev 24846
bundle2: issue remote output as "status" (issue4612) Remote output should be silenced by --quiet. The issue was found while running `test-largefiles-cache.t` so it will get tested once we switch bundle2 by default.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip