Re: svn_client_move7 and mixed-revisions

On 12.03.2013 18:13, Philip Martin wrote:
> 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.

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.

Alternatively, the reversion to the old behaviour should be hidden by
the implementation, not exposed in the public API.

-- Brane

-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com