Matt Mackall <mpm@selenic.com> [Fri, 24 Apr 2015 15:29:02 -0500] rev 24855
merge with i18n
Wagner Bruna <wbruna@yahoo.com> [Thu, 23 Apr 2015 00:07:37 -0300] rev 24854
i18n-pt_BR: synchronized with
5947a68fa271
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.
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.
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.
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.
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.
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.
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.
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.
Laurent Charignon <lcharignon@fb.com> [Thu, 23 Apr 2015 14:27:26 -0700] rev 24845
record: edit patch of newly added files (
issue4304)
I tried to fix this issue in the past and had to revert the fix. This is a
second attempt without the regression we found with the first one.
record defines special headers (of file) as headers whose hunk are not shown
to the user for editing, they are used to represent deleted, moved and new
files. Since we want to authorize editing the patch of newly added file we
make the newly added file with some content not special anymore. This entails
that we have to save their content before applying the backup to be able to
revert it if the patch does not apply properly.
We reintroduce the test showing that newly added files can be edited and that
their content is shown to the user.
Laurent Charignon <lcharignon@fb.com> [Thu, 23 Apr 2015 16:59:11 -0700] rev 24844
record: remove useless line in test
Remove a useless line in test to make the next patch cleaner.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 24 Apr 2015 23:52:41 +0900] rev 24843
revert: apply normallookup on reverted file if size isn't changed (
issue4583)
Before this patch, reverting a file to the revision other than the
parent doesn't update dirstate. This seems to expect that timestamp
and/or size will be changed by reverting.
But if (1) dirstate of file "f" is filled with timestamp before
reverting and (2) size and timestamp of file "f" isn't changed at
reverting, file "f" is recognized as CLEAN unexpectedly.
This patch applies "dirstate.normallookup()" on reverted file, if size
isn't changed.
Making "localrepository.wwrite()" return length of written data is
needed to avoid additional (and redundant) "lstat(2)" on the reverted
file. "filectx.size()" can't be used to know it, because data may be
decoded at being written out.
BTW, interactive reverting may cause similar problem, too. But this
patch doesn't focus on fixing it, because (1) interactive (maybe slow)
reverting changes one (or both) of size/timestamp of reverted files in
many usecases, and (2) changes to fix it seems not suitable for stable
branch.
Pascal Quantin <pascal.quantin@gmail.com> [Thu, 23 Apr 2015 21:23:13 +0200] rev 24842
win32: remove cacert.pem file from Inno Setup installer
Duplicate the modification done in
6e38b6fc4123 for wix installer
so that CA certificates loading works fine with Python 2.7.9+.