Hi David, Thanks *very* much for looking into this and sharing your findings.
* cloned nodes share the version history, so checkins in either > workspace go into the same history. > This is good to know, although am I right in thinking it shouldn't affect my current workflow (make changes in a "preview" workspace, clone/update to "published")? Note that I'm not currently using versioning, but intend to soon. My understanding then is that clone and update should work the same for a node with mix:versionable as for one without (leaving children aside for a moment). It's only when you use checkin, restore etc. that the shared version history becomes apparent. * when updating, jackrabbit at least is using this version history to > destroy as little information as possible. so if a field was updated in > the updating workspace but not in the one we update from, the changed > field is kept. > I'm not sure if I understand this. Presumably for non-versionable nodes, this simply doesn't apply. For versionable nodes, are you saying the update operation looks at the version history and doesn't just compare the base nodes in both workspaces? Imagine this scenario: - Create a (mix:referenceable, mix:versionable) Node N in workspace A - Create a new version of N (checkin), so you have version 1.1 and the base version (I think we can ignore the root version) - Clone N into workspace B, giving a node N' in that workspace (look at the version history for either N or N', and you'll see the same original version 1.1) - Change a property of N, change the same property of N' to a different value - Now try to update N' with the changes from N... what happens? That last part is what I don't understand. I haven't tested it, but I thought that the changes from N would overwrite any changes in N'. Are you saying that actually the version history is used somehow? * jackrabbit currently checks children if they are mix:versionable and > if so, skips them. so you could model your content as versionable for > things that you do want to synchronize separately. > it should be mix:simpleVersionable instead of mix:versionable, i think > jukka created a patch for that, but this will at best come in the next > 2.6 release. i *think* phpcr-odm is currently using > mix:simpleVersionable, but i could be wrong here. Do you mean that Jackrabbit skips mix:versionable nodes when performing an update? Suppose I have nodes like this, where * means the node is versionable: /page* /page/block-1 /page/block-2 /page/sub-page* /page/sub-page/block-1 /page/sub-page/block-2 If I update "/page" from workspace A to workspace B, then should only the following nodes be updated? /page* /page/block-1 /page/block-2 I have tried testing this using the phpcr-api-tests suite, with mix:versionable and mix:simpleVersionable, and in both cases any changes to "/page/sub-page" are copied across when I update "/page". Thanks, Lars.
