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 > > >
signature.asc
Description: OpenPGP digital signature
