SVN-4844: Avoid copies in mixed-revision working copies by default and add --allow-mixed-revisions for copy

Hi,

prompted by IRC discussion, I created

        https://issues.apache.org/jira/browse/SVN-4844

to suggest to change the behaviour of `svn copy` to avoid operations
that will cause bogus tree conflicts on merges later on. The cause of
my little test case has been identified as me doing the copy in a
mixed-revision working copy. The copy works, but records additional
metadata which later breaks merges. The difference in the dump of the
repo is such that, after the block that is identical to what happens
without mixed revs or repo URLs,

Node-path: B
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 1
Node-copyfrom-path: A

there is another block for the file contained in B,

Node-path: B/file
Node-kind: file
Node-action: add
Node-copyfrom-rev: 2
Node-copyfrom-path: A/file
Text-copy-source-md5: f75b8179e4bbe7e2b4a074dcef62de95
Text-copy-source-sha1: 7fe70820e08a1aac0ef224d9c66ab66831cc4ab1

.
With this information in the repository, a merge from A to B will fail
with a merge conflict on B/file already existing.

Would `svn copy` remind me to do `svn up` first (or face consequences
with --allow-mixed-revisions), lots of headache could be avoided.

It was suggested that the logic from `svn merge` in this respect could
be applied to `svn copy`.

Another question for me is why this actually _has_ to break the merge.
I do not know how many instances of this pattern I have in repositories
I interact with. Can we filter out the bad/superfluous metadata from
mixed-rev copies? Can the merge be made more robust to not see a tree
conflict where there is none?

Tree conflicts are the major nemesis of svn users, IMHO, and the usual
prompt for ridicule from proponents of $other_scm. Especially when they
are, from a human perspective, clearly bogus and made up by svn!

So, I hope we can quickly come up with a patch avoiding the creation of
the ‘bad’ copies … but maybe the discussion also produces a change that
makes the bogus tree conflict disappear for existing repositories.

Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg