Branko Čibej <br...@wandisco.com> writes: > On 12.03.2013 18:13, Philip Martin wrote: >> 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. > > I sort of agree with your analysis. Am I right in assuming that the best > solution would be to simply remove the allow_mixed_revisions parameter? > This would make the behaviour of svn_client_move6 change, but that's OK, > IMO, since we do want to always track moves.
Yes, I believe removing allow_mixed_revisions is the solution. Any user of the svn_client_move6 API has to handle errors, and in 1.8 it simply gives an error in more cases. I've been experimenting with a 1.7 client linked to the 1.8 libraries (build the 1.8 libraries with --disable-full-version-match to get this to work). The client calls the legacy svn_client_move6 and gets full 1.8 move tracking: conflicts, updates, etc. when the source is single-rev. But for mixed-rev the libraries silently convert the move to copy+delete without move tracking. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
