On Tue, Jan 08, 2013 at 09:00:38AM +0000, Bert Huijben wrote:
> Local moves and metadata only moves without all kinds of unexpected error
> scenarios are essential for integrations of Subversion tools in third party
> tools.
>
> *Not everybody uses ‘svn’ where move can be an interactive operation.*
I don't think we'll get away without introducing new errors, sorry.
With the current trunk code it is impossible to properly commit or update
mixed-revision moves. If 1.8 ships with the target feature set I have in
mind, such tools will get an error when they attempt to move a mixed-rev WC.
I see that this is a problem when tools linked against 1.7 APIs try to
move things, because they'll run into an unexpected error.
What I suggest is that we revv the move API before release, and keep the
old one around without any move tracking. I.e. we'll keep existing API
users working as they do now, but force new API users to rethink their
approach (or simply catch and handle the error) when they start using 1.8.
It is not a huge problem to degrade a move to copy+delete for such API
users because that's not a regression for them. And really, all we're
trying to do by recording moves is making interactive conflict resolution
for tree conflicts possible. A feature that many users (especially automated
scripts) don't even need!
Just even getting updates of moves working correctly for the single-revision
case is hard enough, and I want to focus on getting that done. I do not
want to tackle mixed-revision moves for 1.8. If you really want that,
then please write the code yourself or find people who are willing to
tackle this problem. I'm sorry to say this but I simply don't have the
time and skills to do this in a reasonable time frame. I don't want to
take responsibility for mixed-revision move support right now.
Received on 2013-01-08 13:09:51 CET