On 12.03.2013 20:48, Philip Martin wrote:
Bert Huijben <[email protected]> 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.
Speaking for TSVN:
I didn't hard code the --force flag (allow_mixed_revisions) but have it
default to 'false'. Never heard complaints about it.
Stefan
