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

svn_client_move7 and mixed-revisions

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Tue, 12 Mar 2013 17:13:34 +0000

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

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:
Received on 2013-03-12 18:33:52 CET

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