On 18.12.12 15:30, Stefan Guggisberg wrote: > On Tue, Dec 18, 2012 at 4:08 PM, Michael Dürig wrote: >> >> >> On 18.12.12 14:43, Thomas Mueller wrote: >>> >>> Hi, >>> >>>>>> 2) Allow inconsistent journals. >>>>> >>>>> >>>>> I guess we don't want that. But the question is how close the journal >>>>> has >>>>> to match the original commit, specially "move" and "copy" operations. If >>>>> they need to be preserved (do they?), then it's complicated. >>>> >>>> >>>> There is no use for a journal which is not accurate. After all, if we >>>> consider implementing rebase (OAK-464) on top of the journal, it has to >>>> be accurate. >>> >>> >>> Yes, I think we should have a consistent journal, if we have a journal. >>> >>> But the question is how close the journal has to match the original >>> commit, specially "move" and "copy" operations. >>> >>> So, do "move" and "copy" operations need to be preserved, or can they be >>> converted to "add node" / "remove node"? >> >> >> Now we are getting somewhere: This is exactly the original topic of OAK-464. >> If the Microkernel converts moves to add/remove, implementing rebase on top >> of that results in moves of big sub trees to become *very* expensive. > > IIRC we didn't consider efficient move operations a design goal. > i guess we can live with non-optimized move operations. Right. However, degrading moves to remove/add node operations limits the size of sub trees which can be moved: if the moved sub tree (serialised to json add node operations) do not fit into heap, moves wont work at all. Michael > > cheers > stefan > >> >> Michael >> >>> >>> >>> Regards, >>> Thomas >>> >>> >>