Only enable the 'incoming_move_file_merge' resolution option if the local change is a file edit.
This resolution option was introduced in r1747727 and accidentally enabled for any local change vs an incoming deletion. So while this resolution handler only supports local edits, it was enabled even for other conflicts, such as those involving locally moved-away files. In that case Subversion was pretending to resolve the conflict when in fact it did not resolve it. The resolution handler in libsvn_client internally failed with a "path not found" error which was masked by 'svn resolve' (since this error is sometimes legitimate) and the conflict marker was still in place after Subversion proudly proclaimed: "Applying recommended resolution 'Move and merge'"
Subversion now tells the truth instead: "Subversion is not smart enough to resolve this tree conflict automatically!"
* subversion/libsvn_client/conflicts.c (configure_option_incoming_move_file_merge): Only configure this option if the local change is an 'edit'.
Remove a useless common ancestor search from the conflict resolver.
* subversion/libsvn_client/conflicts.c (resolve_incoming_move_dir_merge): Stop searching a YCA and then using it as the left-side of the merge source when merging into the move target. Doing so is wrong because it could lead to dubious conflicts since we will end up ignoring mergeinfo. Use the 'incoming old' path and revision as the left-merge side instead, which is properly bound by merge-tracking done during the merge which recorded the conflict. Problem found by code inspection while working on r1851913.