Please read the full mailing list thread. This were the use cases brought up by Eric
"I can envision a highly modular distribution in which two modules (from different owners) may accidentally have paths that collide. So I can see how a repoinit that would fail fast in that scenario could be useful. In other words, if someone else already created a path (with the wrong types) that you are not expecting to be there, then failing right away seems like a reasonable solution.” Konrad > On 19. Dec 2022, at 12:50, Bertrand Delacretaz <[email protected]> wrote: > > Hi, > > I agree with deprecating "create path" and implementing new instructions. > > But I'm not sure why you would need two new instructions: > > Konrad Windszus <[email protected]> wrote: > ... >> a) ensure node (for creating or updating node(s) with primary and mixin type) >> b) update node (for just updating existing node(s) with primary and mixin >> type). > ... > > In both cases, you want the specified nodes to be exactly as described > in the statement, so why two instructions? > > What would "update node" do if not all nodes exist yet, fail? Do > nothing? Both are not good IMO. > > Whoever writes the repoinit script specifies an end state, I don't > think they care about the previous state, so I think just "create > node" is sufficient and simpler to implement. > > But it's actually not a single node that's being created or updated, > it's the whole subtree, when you write something like > > create node (nt:folder) /one(mixin nt:art)/step(mixin nt:dance)/two/steps > > You're actually touching up to 4 nodes...I think "create nodes" or > "set nodes" is a better name for this new instruction. > > -Bertrand
