svn_client_move7 is new in 1.8, it has two new boolean parameters compared to svn_client_move6: allow_mixed_revisions and metadata_only. The metadata_only flag is fine but allow_mixed_revisions is a bit odd:
* If @a allow_mixed_revisions is @c FALSE, #SVN_ERR_WC_MIXED_REVISIONS * will be raised if the move source is a mixed-revision subtree. * If @a allow_mixed_revisions is TRUE, a mixed-revision move source is * allowed. This parameter should be set to FALSE except where backwards * compatibility to svn_client_move6() is required. In 1.7 a call to svn_client_move6 produces copy+delete with no move tracking. In 1.8 a call to svn_client_move7 with allow_mixed_revisions=FALSE, the recommended setting, produces copy+delete with move tracking or an error. But if allow_mixed_revisions=TRUE things are more complicated. The result is copy+delete with move tracking some of the time and copy+delete without move tracking at other times. The legacy API svn_client_move6 sets allow_mixed_revisions=TRUE to enable the behaviour. I think this concept of legacy behaviour is odd. Are there reasons to prefer want the old untracked copy+delete? I can't see why an application would want that. I see that the new behaviour will result in errors where the old behaviour would do a copy+delete but I think the error is better. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
