On 6.3.13 8:16, Marcel Reutegger wrote:
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.
Ack.
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().
Ack.
what is the reason MK.commit() explicitly says deleting a concurrently
deleted node must be merged?
Legacy.
Michael
regards
marcel
[0]
http://wiki.apache.org/jackrabbit/Conflict%20handling%20through%20rebasing%20branches
