[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn_client_move7 and mixed-revisions

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Tue, 12 Mar 2013 18:07:12 +0000

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.