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
