Hi, >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 conflicts. 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. Regards, Thomas
