To an api user that is halfway through a refactoring, you can’t say: you can’t move this file directory. Go undo everything you did before.
For ‘svn’ a move is a single operation that may fail with some warning, but to an aplication that uses our library (TortoiseSvn, Eclipse, AnkhSVN) a move is a small operation inside a larger scope. For these clients just saying a move might or might not work is breaking compatibility with Subversion 1.0-1.7. They prefer the copy behavior over a broken working copy, as that doesn’t break the external refactoring tool that they wrap. (They just record operations. They can’t alter what to do based on a later error) Making mixed revision moves work properly is of course the real prefered solution, but if we postpone that to a future version this is the next best thing we can do. The api version of ‘svn mv A B’ should have the same behavior as in 1.0-1.6. Tracking moves where we can is nice to our users and better then always requiring copy+delete for these tools. Bert Sent from Windows Mail *From:* Philip Martin <[email protected]> *Sent:* March 12, 2013 6:33 PM *To:* [email protected] *Subject:* svn_client_move7 and mixed-revisions 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
