On 12.03.2013 20:48, Philip Martin wrote:
> 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.
>
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
Received on 2013-03-12 20:54:29 CET