On 15 March, Bert Huijben wrote:
> Julian Foad wrote:
>> === Pre-conflict and post-conflict operating modes.
>>
>> The problem is basically that we have confused two different operating
>> modes -- with different purposes and requirements -- for such a callback:
>>
>> (1) Sometimes we call the CB before raising a conflict, in order to
>> decide whether we need to record a conflict or can immediately resolve it.
OK, I got that wrong: we always store the conflict in the WC first. What confused me was that we call the CB before sending a notification, and if the CB resolves it then we notify with status 'changed' or whatever rather than status 'conflicted'.
>> (2) Other times we record a conflict in the WC and then, later, we call
>> the CB as a way of presenting the stored conflict to the client. In this
>> case we want the user to be offered a range of interactive options
>> including examining the conflict and the WC and making changes to the WC.
[...]
>> === The 'adds_as_modification' flag
>>
>> Some existing APIs have an 'adds_as_modification' flag, which says don't
>> raise a tree conflict for add-onto-add (if the node kind is the same), but
>> instead resolve the potential conflict by collapsing the two adds and
>> treating the local add as the desired new value, so the result looks like
>> a modification -- or non-modification -- of the incoming added node.
>>
>> This flag is an example of a "mode 1" pre-determination for certain kinds
>> of conflict. This kind of functionality should be provided by a mode-1
>> conflict resolution callback.
>>
>> It is present in: svn_client_update4(), svn_client__update_internal(),
>> svn_wc__get_update_editor().
>
> This was introduced right before introducing tree conflicts.
>
> Personally I would say we should move this behavior to a compatibility
> conflict resolver and remove it from the update/switch handling.
Makes sense.
There is a similar parameter in some of the merge APIs: the 'force_delete' flag, which was called 'force' until I renamed it recently. It allows to delete a file whose content differs from the source-left version, or a locally modified directory, or an unversioned item, instead of raising a tree conflict. The same principle applies here: this behaviour should be implemented by a conflict resolver.
Maybe I'll have a go at replacing those with resolver callbacks, not because it's important to get rid of these parameters from the API but rather because it will provide a good test for the resolver infrastructure, as this is exactly the sort of thing I have envisaged the system should be capable of.
- Julian
Received on 2013-03-28 22:02:38 CET