On 15.1.13 10:23, Marcel Reutegger wrote:
I looked into why 2 tests failing in MicroKernelIT for MongoMK. One of
them is conflictingMove test. This test passes for MicroKernelImpl and it
looks like the reason is MicroKernelImpl always commits against head. Take
a look at CommitBuilder around line 112. There's a check whether baseRevId
is not equal to currentHead, and if so, the staged tree is reset to
currentHead and the operation is retried. This effectively means that the
operation is committed against head, right?
hmm, not sure. I'd first have to look at the code. if it just blindly commits to
head then it's certainly wrong and it also means it wouldn't detect the
conflict, right? So, I guess what it does is some kind of rebase.
Yes, the H2 MK does some kind of rebase if the commit is not against the
current head: it tries to reapply all changes against the current head
an later tries to merge the resulting changes into trunk. However this
results in a race condition. See
https://issues.apache.org/jira/browse/OAK-532
We recently changed CommitCommand to commit against baseRevisionId
instead
of head but I'm thinking maybe we should change it back to committing
against head? Or maybe we commit against baseRevisionId but we add some
kind of a conflicting commit detection (although I'm not too sure how we'd
detect conflicting commits easily). WDYT?
this is missing right now. merging with the *head* revision tree is done in
CommitCommandNew.mergeNodes(). that is, mergeNodes() basically does
the rebase I mentioned above. I recently added a FIXME to this method.
I think this is the place where we'd need to find out if there is a conflict.
In a nutshell here is what I think we should do: MK.commit should fail
on all but conflicts which are trivially merged. This will not be a
problem for oak-core since oak-core applies changes to private branches
and will merge these on Session.save. Before merging, branches are
rebased and that's the place where the more complicated conflict
handling should go. Due to rebasing the subsequent merge will not
conflict any more.
See my POC work on https://issues.apache.org/jira/browse/OAK-536 for how
such a rebase operation could look like. Note that the current
implementation is not complete yet since it just throws an exception on
conflicts. I will soon update this to a more complete implementation
which correctly annotates conflicts such that oak-core can further
handle these.
Also note how such an implementation will also solve OAK-464 and OAK-548.
Michael
