Bert Huijben <bert_at_qqmail.nl> writes:
> 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.
Not undo, run update. If update brings in no changes and just bumps
revisions it is a trivial operation. Is that not possible? If update
brings in real changes then the user has to do that before committing.
Isn't it better to do it before the move rather than after the move?
> 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.
It still doesn't make sense to me.
When we changed merge to check for a single revision working copy did
all the GUIs hard-code --force and bypass the check? I can see that a
GUI might give users the option but you seem to be saying that GUIs need
to disable the check altogether.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Received on 2013-03-12 20:48:57 CET