Re: Consistency between 'update' and 'switch' APIs

On 13.03.2013 17:29, Julian Foad wrote:
> I (Julian Foad) wrote:
>
> [...]
>> PROPOSAL
>>
>> - svn_ra_do_update2(): revise to svn_ra_do_update3(), add the
>> 'ignore_ancestry' option there too, and use two pools while we're at
>>
>> it. Track this change in the RA vtable 'update' method, protocols, etc.
>>
>> - svn_wc__get_switch_editor(): add 'adds_as_modification'.
>>
>> - svn_client__update_internal(), svn_client_update4(): add
>> 'ignore_ancestry'.
>>
>> - svn_client__switch_internal(), svn_client_switch4(): add
>> 'adds_as_modification'.
>>
>>
>> RATIONALE
>>
>> Do I really have to explain why Consistency is Good?
> Consistency alone doesn't require us to add the options where missing; we could also remove them where present. These options exist because we decided at some point that we wanted them, and I think we still want them and we definitely still need them for backward compatibility.

Actually, if we're revving an API, it's just as valid to /remove/
options as it is to add them. IMO.
The backwards-compat behaviour can be encapsulated in the implementation.

So, for example, we could go ahead and remove the ignore-ancestry option
from switch.

-- Brane

-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com