On Thu, 2010-02-18, Daniel Näslund wrote:
> Hi!
>
> My initial thought when I started writing on a spec for a TC resolver
> was that it would involve a lot of quirks and edge cases handled solely
> in subversion/svn/conflict-callbacks.c. That the svn resolver would only
> serve as a proof-of-concept for other API users. But if I could
> implement the ---accept options in libsvn_wc/conflicts.c we would have a
> firm foundation for others to build upon.
>
> I could implement each --accept option in libsvn_wc/conflicts.c and
> write test cases for each. Is this a possible way to go? Many of the
> --accept options would require much more than the existing ones for
> property and text conflicts.
Here is a good time to say something that has always been in my mind,
about the layering of the decision making points in the code, when a
conflict is initially discovered.
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
...
}
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.
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
Received on 2010-02-19 13:50:09 CET