Path conflict checking for merging was introduced in 989e884d1be9, and its child (7a8a16f8ea22) added the functionality for clearing unknown files. Then they were disabled behind an experimental config in 2a774cae3a03. In theory, I would have expected this to return to the 989e884d1be9^ behavior. The Windows tests say different.[1] (Specifically test-audit-path.t. I didn't look to see if the other failure is related.) Sadly, these messages were either globbed away or missing completely in the history. Prior to 989e884d1be9, the error for no-symlink was: abort: $TESTTMP\target\back/test: The system cannot find the path specified. In 989e884d1be9 (and the same for it's child where unknown was handled), it became: back: is both a file and a directory abort: destination manifest contains path conflicts If the disabled experimental knob is grafted back to 989e884d1be9, the error is: abort: $TESTTMP\target\back/test: The system cannot find the path specified. And grafted onto the child, the result is a successful update, as has been seen in recent test failures. I think the fact that the #if symlink side of things is actually dealing with a symlink and getting an error, is probably masking this. [1] https://buildbot.mercurial-scm.org/builders/Win7%20x86_64%20hg%20tests/builds/425/steps/run-tests.py%20%28python%202.7.13%29/logs/stdio
Bug was set to UNCONFIRMED for 30 days, bumping
Fixed by https://mercurial-scm.org/repo/hg/rev/656ac240f392 Matt Harbison <matt_harbison@yahoo.com> context: skip path conflicts by default when clearing unknown file (issue5776) Prior to adding path conflict checking in 989e884d1be9, the test-audit-path.t tests failed as shown here (but it was globbed away). 989e884d1be9 made it fail with a message about the destination manifest containing a conflict (though the no-symlink case wasn't updated). When the path conflict checking was gated behind an experimental config in 2a774cae3a03^::2a774cae3a03, the update started erroneously succeeding here. It turns out that the child of 989e884d1be9 is the origin of this change when path conflict checking is disabled, as shown by grafting the experimental config range on top of it. What's happening here is merge.batchget() is writing the symlink 'back' to wdir (but as a regular file for the no-symlink case), and then tries to write 'back/test', but calls wctx['back/test'].clearunknown() first. The code that's gated here was removing the newly written 'back' file, allowing 'back/test' to succeed. I tried checking for the dir components of 'back/test' in dirstate, and skipping removal if present. But that didn't work because the dirstate isn't updated after each file is written out. This is the last persistent test failure on Windows, so the testbot should start turning green now. \o/ (please test the fix)
Bug was set to TESTING for 8 days, resolving