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.
Sent from Windows Mail
*From:* Philip Martin <philip.martin_at_wandisco.com>
*Sent:* March 12, 2013 6:33 PM
*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
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 20:09:52 CET