[
https://issues.apache.org/jira/browse/OAK-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508698#comment-13508698
]
Thomas Mueller commented on OAK-464:
------------------------------------
The title of this issue is "RootImpl.rebase() doesn't handle move operations
correctly", to me it sounds like this would be best solved in oak-core.
Jukka, in an earlier comment, you wrote:
> Given the move in the first commit, the second commit in this case should be
> interpreted as "+/b/x:0"
Now you write :
> I think it's fine if the MK chooses to simply throw an exception in such a
> case.
I'm a bit confused now, which would be the right way? If both is fine, wouldn't
that mean the original problem (move operations) still need to be handled in
oak-core if the MicroKernel doesn't handle this conflict, so are still
inefficient?
> instead of oak-core having its own, slightly different way of handling
> conflicts.
I think oak-core should know about the original JCR operations, so it should be
a much better position to handle conflicts than the MicroKernel.
I don't understand what problem we want to solve here, if not just more
functionality down from oak-core to the MicroKernel. I guess it would help if
you provide a concrete example, instead of high level description?
> RootImpl.rebase() doesn't handle move operations correctly
> ----------------------------------------------------------
>
> Key: OAK-464
> URL: https://issues.apache.org/jira/browse/OAK-464
> Project: Jackrabbit Oak
> Issue Type: Bug
> Reporter: Michael Dürig
>
> Doing {{RootImpl.rebase()}} causes moves to be changed to remove followed by
> add. Which causes moves of large sub trees to become very expensive.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
