On Thu, 2016-10-27 at 10:58 +0000, Tomek Rekawek wrote: > Hello, > > let me describe the use cases we have in mind for the multiplexing > node store in a more detailed way. I hope it’ll allow to plan a few > (well, two) milestones for the implementation.
Thanks for providing the extra context, Tomek. (snip) > Since the “private” and “global” repositories are really extracted > parts of the same “initial” repository, we don’t need to worry about > the consistency - as at the node store level “private” + “global” > repository === “initial” repository, which, as we know, is > consistent. If we have referenceable nodes or versionable nodes in the 'private' repository then it will be inconsistent, as they point to data maintained under the 'global' store. So we need to prevent such 'corrupt' mounts from being used. > This scenario (a) is possible to have with the current version of the > multiplexing node store patch. That’s why I think it’d be a good idea > to document it (putting an emphasis on fact that splitting an > existing repository into parts using oak-upgrade is right now the > *only* way to get a consistent multiplexing node store repository) > and merge. The patch is already quite big and I think that postponing > it will make it hard to track the progress here. I second that, the patch set is quite large, and we will need to build on it anyway. I would suggest clarifying as soon as possible: 1. If the current design is something that can be incorporated in Oak ( I would hope so :-) ) . 2. What are the implementation changes ( if any ) that need to be done for an initial contribution. Note I added checks for read-only mounts as discussed after my initial email. This will definitely see more fixes and tweaks in the following weeks, but to get those in we need feedback from consuming parties, which is much easier to get with an 'official' Oak SNAPSHOT build. Thanks, Robert
