merge with i18n

i18n-pt_BR: synchronized with dfc6663f97ca

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.

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

tests: expand flags to long form in test-largefiles-update.t I spent some time confused by this test. I'm pretty sure that this line intends to be cleaning the dirstate, not checking that it's clean before updating: the preceding #if block leaves the dirstate clean in the noexec case, and dirty in the exec case, so we can't expect consistent behavior across that platform variation. A subsequent patch will modify this command to use --clean instead of --check. I'll elaborate in that patch about the hypothetical bug here.

merge: fix crash on criss cross merge with dir move and delete (issue5020) Work around that 'dm' in the data model only can have one operation for the target file, but still can have multiple and conflicting operations on the source file where the other operation is a 'rm'. The move would thus fail with 'abort: No such file or directory'. In this case it is "obvious" that the file should be removed, either before or after moving it. We thus keep the 'rm' of the source file but drop the 'dm'. This is not a pretty fix but quite "obviously" safe (famous last words...) as it only touches a rare code path that used to crash. It is possible that it would be better to swap the files for 'dm' as suggested on https://bz.mercurial-scm.org/show_bug.cgi?id=5020#c13 but it is not entirely obvious that it not just would create conflicts on the other file. That can be revisited later.

tests: use 'f' in test-merge-criss-cross.t to prepare for recursive dumping Prepare for adding a test case with files in a directory.

util: make sortdict.keys() return a copy dict.keys() is documented to return a copy, so it's surprising that sortdict.keys() did not. I noticed this because we have an extension that calls readlocaltags(). That method tries to remove any tags that point to non-existent revisions (most likely stripped). However, since it's unintentionally working on the instance it's modifying, it sometimes fails to remove tags when there are multiple bad tags in a row. This was not caught because localrepo.tags() does an additional layer of filtering. sortdict is also used in other places, but I have not checked whether its keys() and/or __delitem__() methods are used there.

test-highlight: add normalization rule for Pygments 2.2 The test failed on Debian sid because of new class="vm".

tests: account for different newline behavior between Solaris and GNU grep GNU grep, when emitting a matching line that doesn't have a terminating newline, will add an extra newline. Solaris grep passes the original line through without the newline. This causes differences in test output when looking at the last line of the output of get-with-headers.py, which doesn't usually emit (and certainly doesn't guarantee) a terminating newline. Both grep implementations succeed in matching the requested pattern, though, so rely on specifying the full pattern on grep's commandline instead of expecting it in the output, and send the output to /dev/null.