i18n-pt_BR: synchronized with efebc9f52ecb

revlog: add an experimental option to mitigated delta issues (issue5480) The general delta heuristic to select a delta do not scale with the number of branch. The delta base is frequently too far away to be able to reuse a chain according to the "distance" criteria. This leads to insertion of larger delta (or even full text) that themselves push the bases for the next delta further away leading to more large deltas and full texts. This full text and frequent recomputation throw Mercurial performance in disarray. For example of a slightly large repository 280 000 files (2 150 000 versions) 430 000 changesets (10 000 topological heads) Number below compares repository with and without the distance criteria: manifest size: with: 21.4 GB without: 0.3 GB store size: with: 28.7 GB without 7.4 GB bundle last 15 00 revisions: with: 800 seconds 971 MB without: 50 seconds 73 MB unbundle time (of the last 15K revisions): with: 1150 seconds (~19 minutes) without: 35 seconds Similar issues has been observed in other repositories. Adding a new option or "feature" on stable is uncommon. However, given that this issues is making Mercurial practically unusable, I'm exceptionally targeting this patch for stable. What is actually needed is a full rework of the delta building and reading logic. However, that will be a longer process and churn not suitable for stable. In the meantime, we introduces a quick and dirty mitigation of this in the 'experimental' config space. The new option introduces a way to set the maximum amount of memory usable to store a diff in memory. This extend the ability for Mercurial to create chains without removing all safe guard regarding memory access. The option should be phased out when core has a more proper solution available. Setting the limit to '0' remove all limits, setting it to '-1' use the default limit (textsize x 4).

rebase: also test abort from pretxnclose error Different hooks will have different properties so we cover more hooks to catch further regressions.

rebase: reinforce testing around precommit hook interrupting a rebase Different hooks will have different properties so we cover more hooks to catch further regression.

rebase: provides test case for (issue5610) The 4.2 release introduces a regression regarding the behavior of rebase with some hook failures. We add the tests from the bug report from Henrik Stuart to our test base to prevent further regression on this.

rebase: backed out changeset cf8ad0e6c0e4 (issue5610) Having a single transaction for rebase means the whole transaction gets rolled back on error. To work around this a small hack has been added to detect merge conflict and commit the work done so far before exiting. This hack works because there is nothing transaction related going on during the merge phase. However, if a hook blocks the rebase to create a changeset, it is too late to commit the work done in the transaction before the problematic changeset was created. This leads to the whole rebase so far being rolled back. Losing merge resolution and other work in the process. (note: rebase state will be fully lost too). Since issue5610 is a pretty serious regression and the next stable release is a couple day away, we are taking the backout route until we can figure out something better to do.