dirstate: fix filefoldmap incosistency on file delete The _filefoldmap is not updated in when files are deleted from dirstate. In the case where the file with the same but differently cased name is added afterwards it renders _filefoldmap incorrect. Those steps must occur to for a problem to reproduce: - call status (with listunknown=True), - update working rectory to a commit which does a casefolding change (A -> a) - call status again (it will show the file "a" as deleted) Unfortunately I'm unable to write a test for it because I don't know any core-mercurial command able to reproduce those steps. The bug was originally spotted when hgwatchman was enabled. It caused the changeset contents change during hg rebase (one file unrelarted to changeset was deleted in it after rebase). The hgwatchman is able to hit it because when hgignore changes the hgwatchmans overridestatus is calling original status with listunknown=True.

wix: style-coal.css has been renamed

merge with stable

clonebundles: fix typo s/comand/command/

posix: retry on symlink race in checklink Multiple threads might attempt to check links with the same temporary name. This would cause one side to get an EEXIST error and wrongly fail the support check. Here, we simply retry if our temporary name exists.

changegroup: back code change of e7c618cee8df out The previous changeset is a simpler way of fixing issue4934 without changing the spirit of the code. We can remove the dual call to 'delayupdate' but we keep the tests to show that the issue is still fixed.

changegroup: call 'prechangegroup' hook before setting up write delay The 'prechangegroup' interfere with 'delayupdate' logic because it trigger the one time call of 'changelog._writepending' (see issure4934). There is no reason not to call that hook before setting up 'delayupdate' so we move the call a bit earlier to avoid interference.

changegroup: fix the scope of a try finally The try finally is here to ensure we release the just-created transaction. Therefore we should not do half a dozen operations before actually entry the try scope.

encoding: re-escape U+DCxx characters in toutf8b input (issue4927) This is the final missing piece in fully round-tripping random byte strings through UTF-8b. While this issue means that UTF-8 <-> UTF-8b isn't fully bijective, we don't expect to ever see U+DCxx codepoints in "real" UTF-8 data, so it should remain bijective in practice.

encoding: use getutf8char in toutf8b This correctly avoids the ambiguity of U+FFFD already present in the input and similar confusion by working a character at a time.