Wed, 01 Feb 2017 10:15:10 -0600 merge with i18n stable 4.1
Kevin Bullock <kbullock+mercurial@ringworld.org> [Wed, 01 Feb 2017 10:15:10 -0600] rev 30861
merge with i18n
Wed, 01 Feb 2017 08:47:11 -0200 i18n-pt_BR: synchronized with dfc6663f97ca stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Wed, 01 Feb 2017 08:47:11 -0200] rev 30860
i18n-pt_BR: synchronized with dfc6663f97ca
Wed, 01 Feb 2017 02:10:30 +0100 merge: more safe detection of criss cross merge conflict between dm and r stable
Mads Kiilerich <mads@kiilerich.com> [Wed, 01 Feb 2017 02:10:30 +0100] rev 30859
merge: more safe detection of criss cross merge conflict between dm and r 41f6af50c0d8 introduced handling of a crash in this case. A review comment suggested that it was not entirely obvious that a 'dm' always would have a 'r' for the source file. To mitigate that risk, make the code more conservative and make less assumptions.
Mon, 30 Jan 2017 18:03:17 -0500 tests: correct (I think) command in test-largefiles-update stable
Augie Fackler <augie@google.com> [Mon, 30 Jan 2017 18:03:17 -0500] rev 30858
tests: correct (I think) command in test-largefiles-update When this test was introduced, it used the short-form of all the flags on this update invocation. I suspect, based on the "start with clean dirstates" comment and the fact that the no-exec branch of the #if guard leaves dirstate clean, that this should have been 'update -qCr' instead of 'update -qcr', but that a bug in largefiles --check handling left this problem unnoticed. I'll leave a breadcrumb further up about the current failure mode in the hopes that we can fix this some day. This was previously discussed in [0] but the trail in that thread goes cold after a few replies. Given that this is still a flaky test, that appears to only be passing by bad fortune, I think it's worth correcting the code of the test to make a correct assertion, and to keep track of the suspected bug with some other mechanism than an invalid test (if we had support for "expected failure" blocks this might be a worthwhile use of them?). 0: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-October/089501.html
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 tip