It is possible to trick 'svn resolve --accept mc' into updating what is
effectively a mixed-rev state. The move source appears to be in a single-rev
state but has in fact only been bumped into single-rev, with no actual changes
applied to working files.
It seems the root of the problem is somewhere in 'svn update'.
Running 'svn update' on a per-node basis within a tree-conflicted mixed-rev move
source can result in a corrupt working copy state where the working copy
believes it contains a single-rev subtree with all nodes at rN, but where file
content corresponds to content from revisions other than rN.
Major