Neels J Hofmeyr wrote:
> 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 would want it to be able to know and modify its behaviour based on
what kind of operation is happening. Every callback should take a
callback baton so that the higher level code can pass information such
as this to it.
- Julian
> >
> > 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
Received on 2010-02-19 15:25:28 CET