On Thu, 2020-07-09 at 15:35 +0000, Marcel Reutegger wrote: > Hi, > > On 09.07.20, 15:39, "Robert Munteanu" <[email protected]> wrote: > > The details are rough and my memory of the implementation is not > > that > > good > > Same here. > > Besides the problem with a potential two phase commit, I think the > biggest concern was impact of a change in a mounted subtree on > repository wide data structures. E.g. what happens when an access > control entry is added to such a subree? How are indexes updated for > nodes changed in the subtree?
Well, it depends. The current check when merging changes is simple - only allow them to the default (read-write) mount. What I propose is allow writes to all mounts under given circumstances. For instance (all examples inside a non-default mount): - if there is an observation listener that should be triggered, fail the commit - if an index should be updated and we know we can't do that, fail the commit The downside is that it is less predictable that a 'plain' read-only situation and can be confusing for users of the repository. Or that, due to the way the repository is configured, effectively no changes can be persisted ( e.g. observation listener for all of /apps ). > > I'm also wondering whether and where the current implementation > assumes > mounted subtrees are read-only and takes short cuts. These would need > to > be changed as well. Yes, those implementations need to be revisited as well. I am a bit optimistic here since for instance indexing can write to a separate location; this is one of the steps of preparing a composite node store. Thanks, Robert
