Branko Čibej <brane_at_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
Received on 2013-03-12 19:07:59 CET