Hi, > My take on this was: when we rebase internally anyway, why not make this > rebase available externally so branches could rebase themselves and thus > make it easier for the commit later on? AFAICS the internal rebase would > either have to be on something which pretty much resembles a private > branch (optimistic locking) or would need to be synchronised for > serialising concurrent commits. The latter would result in a very fat > lock and is not what we want. FYI the H2 based Microkernel tries to > implement commit without such a fat lock and fails. See OAK-532.
I don't think this is an implementation issue, but rather a design problem as you noted in the discussion on the dev list referenced in OAK-532 (http://markmail.org/message/4xwfwbax3kpoysbp) Concurrent deletes of nodes must IMO fail for the reasons you stated and the test you provided in OAK-532. I think we should remove the example from the MK.commit() JavaDoc and refer to the conflict definition of MK.rebase(). after all this is how I understand your proposal [0] and implication on MK.commit(). what is the reason MK.commit() explicitly says deleting a concurrently deleted node must be merged? regards marcel [0] http://wiki.apache.org/jackrabbit/Conflict%20handling%20through%20rebasing%20branches
