debian: update copyright years

debian: update mailing list address

Added signature for changeset e1526da1e6d8

Added tag 4.1 for changeset e1526da1e6d8

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.