[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Conflict resolver callback design

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 28 Mar 2013 21:02:04 +0000 (GMT)

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.