[ 
https://issues.apache.org/jira/browse/OAK-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940731#comment-13940731
 ] 

Michael Dürig commented on OAK-1553:
------------------------------------

To overcome above problem I suggest to refine the definition for the 
{{addExistingNode}} conflict as follows:

{code}
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.

Two nodes can't be merged if they contain properties of the same name whose 
values differ or if they contain child nodes of the same name that can't be 
merged.

The result of merging two nodes M and N that can be merged contains
* the union of all properties from M and N,
* all nodes from M whose name is not in N,
* all nodes from N whose name is not in M,
* the results from merging the child nodes whose names are both in M and N.
{code}

> 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)

Reply via email to