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