jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: MicroKernelIT#conflictingMove
Date Tue, 15 Jan 2013 11:48:22 GMT

>So I guess I need to understand why it
>is important to commit against base revision in CommitCommandNew.

First, I had a really hard time understanding why we need a base revision
in the commit method.

We found a case where the base revision does make a difference, this case
is documented in the MicroKernel API: "deleting a node is allowed if the
node existed in the given revision, even if it was deleted in the
meantime." In other words: if the commit contains a delete operation for a
node that no longer exists, then the commit succeeds if this node still
existed at the base revision of the commit (so that the delete operation
is ignored). The MicroKernel API doesn't say much else about how to merge
conflicts (merging is not further specified).

But now actually I think it would be better if the commit would fail when
this occurs (when trying to delete a node that is already deleted),
because it would simplify the definition of a conflict (so we can document
and test all possible cases), simplify the code, and allow to detect more

Instead of the MicroKernel trying to merge changes, I would prefer if the
MicroKernel would fail if a node was changed, moved or deleted after the
base revision of a commit. That way, the MicroKernel API would still need
a base revision in the commit call (the base revision would arguably be
even more important), but the behaviour would slightly change.


View raw message