RE: svn_client_move7 and mixed-revisions

To an api user that is halfway through a refactoring, you can’t say: you
can’t move this file directory. Go undo everything you did before.

For ‘svn’ a move is a single operation that may fail with some warning, but
to an aplication that uses our library (TortoiseSvn, Eclipse, AnkhSVN) a
move is a small operation inside a larger scope.

For these clients just saying a move might or might not work is breaking
compatibility with Subversion 1.0-1.7. They prefer the copy behavior over a
broken working copy, as that doesn’t break the external refactoring tool
that they wrap. (They just record operations. They can’t alter what to do
based on a later error)

Making mixed revision moves work properly is of course the real prefered
solution, but if we postpone that to a future version this is the next best
thing we can do.

The api version of ‘svn mv A B’ should have the same behavior as in
1.0-1.6. Tracking moves where we can is nice to our users and better then
always requiring copy+delete for these tools.

Bert

Sent from Windows Mail

 *From:* Philip Martin <philip.martin_at_wandisco.com>
*Sent:* March 12, 2013 6:33 PM
*To:* dev_at_subversion.apache.org
*Subject:* svn_client_move7 and mixed-revisions

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.

--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download