[
https://issues.apache.org/jira/browse/OAK-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13941059#comment-13941059
]
Michael Dürig commented on OAK-1553:
------------------------------------
Maybe a better approach is not to specify the exact merging behaviour in the
contract but leave the details to the implementations:
{noformat}
addExistingNode: A node has been added that can't be merged with a node of them
same name
that has been added to the trunk. How and whether merging takes place is up to
the implementation.
Merging must not cause data to be lost however.
{noformat}
At least document and segment nodes stores and {{AbstractRebaseDiff}} should
still implement the algorithm sketch in my previous comment.
> More sophisticated conflict resolution when concurrently adding nodes
> ---------------------------------------------------------------------
>
> Key: OAK-1553
> URL: https://issues.apache.org/jira/browse/OAK-1553
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, mk, mongomk, segmentmk
> Reporter: Michael Dürig
> Assignee: Michael Dürig
> Fix For: 0.20
>
>
> {{MicroKernel.rebase}} currently specifies: "addExistingNode: A node has been
> added that is different from a node of them same name that has been added to
> the trunk."
> This is somewhat troublesome in the case where the same node with different
> but non conflicting child items is added concurrently:
> {code}
> f.add("fo").add("u1"); commit();
> f.add("fo").add("u2"); commit();
> {code}
> currently fails with a conflict because {{fo}} is not the same node for the
> both cases. See discussion http://markmail.org/message/flst4eiqvbp4gi3z
--
This message was sent by Atlassian JIRA
(v6.2#6252)
