Re: [RFC] v2 Tree conflict resolver spec.

Julian Foad wrote:
>
> I believe it should be a low level job [1] to detect when a (potential)
> tree conflict is happening, and a higher-level job to decide how to
> resolve the (potential) conflict. The low level should pass the details
> to the higher layer, and the higher layer can say something like:
>
> {
> if user-option is ACCEPT-THEIRS or ACCEPT-MINE or ...:
> return user-option
>
> switch (tree-conflict-type):
>
> delete+edit:
> choice = interactive-resolve(...)
> return choice
>
> add+add:
> if same-content(...):
> return ACCEPT-THEIRS # THEIRS or MINE, doesn't matter
> choice = interactive-resolve(...)
> return choice
>
> ...
> }

Hmm, would such higher layer also need to distinct between TC during
update/switch and merge?

>
> I say "(potential) conflict" because even in a case like delete+delete
> or add+add when the two nodes conflicting are identical and most users
> just want it resolved automatically, I think the low level should pass
> the details to the higher layer, and the higher layer can say "if it's
> delete+delete then return ACCEPT-THEIRS" or similar. Even if this
> decision is hard-coded in the higher layer rather than customizable, I
> believe that having it there will make a much better design than if the
> lower layer made that decision and didn't bother to ask the higher
> layer.

I like that :)

The low layer would be check_tree_conflict() in _wc/update_editor.c and <the
code that determines parameters passed to tree_conflict() and
tree_conflict_on_add()> in _client/merge.c, of which the result could be run
by a common higher-layer function, after which the lower code carries out
the actions indicated (like now, e.g. where the code decides to fall through
the 'delete' code path in case of reason_deleted during update...)

~Neels

>
> So this is a bit like the idea of the existing "resolver callback",
> except that that was only trying to pass information about certain kinds
> of conflict that we thought really needed the user's input. Instead of
> that, I think we should have a callback that passes references to all
> the information that the higher layer might need in order to make a
> decision. And it should do it for every case where two changes are being
> combined in the same node.
>
> I'm only talking about the layering of where the decisions are made. I'm
> not saying where the code should be that performs the action requested.
> (So when my example says "return user-option" it might instead need to
> say "perform user-option; return DONE". Or whatever.)
>
>
> [1] The code is in libsvn_wc for updates, libsvn_client for merges.
>
> - Julian
>
>
>> What to do?
>> ============
>> Finish the resolver spec of course.
>> Make svn resolved able to handle states other than 'working'
>> |-> We need to store the tree conflict data on the same node instead of
>> | its parent.
>> |-> Things would be cleaner if we stored the different versions of a
>> node in the db instead of temp files.
>>
>> Daniel
>
>
>