hi, that is not entirely true. if you checkin A, then B (and the entire subtree is copied, since B is not versionable (irrespective of the OPV of B).
3.13.9 Versionable State [...] 5. For each child node C of N where • C has an OPV of COPY, a copy of the entire subgraph rooted at C (regardless of the OPV values of the sub-items) is added to the frozen node, preserving the name of C and the names and values of all its sub-items. [...] if you checkin B, then all C's should be not copied if they have a OPV=VERSION: 3.13.9 Versionable State [...] 6. For each child node C of N where: • C has an OPV of VERSION Under simple versioning, the same behavior as COPY. Under full versioning, if C is not mix:versionable, the same behavior as COPY. Under full versioning, if C is mix:versionable, then a special nt:versionedChild node with a reference to the version history of C is substituted in place of C as a child of the frozen node. [...] So you statement: "... however the recursive copy terminates at each versionable node encountered further below in the subtree, " is not correct. where did you read this? regards, toby On Wed, Mar 3, 2010 at 10:02 PM, Davide Maestroni <[email protected]> wrote: > Hi Alex, > > thank you for your suggestions, now I have a clearer idea about the > versioning of child nodes. > Though I still have one doubt. In my repository I have a parent-child > structure like this: > > A (mix:versionable, nt:unstructured) > ^ > | > B (nt:unstructured) > ^ > | > C (mix:versionable, nt:unstructured) > ^ > | > D (nt:file) > ^ > | > E (nt:resource) > > Where the OnParentVersion attribute for child nodes, in the node type > definition of A, B and C, is always VERSION. > As per what written in paragraph 8.2.11.2 of JCR 1.0 specifications ("If *C* > is > not versionable then the behavior of *COPY*applies on *checkin*, however the > recursive copy terminates at each versionable node encountered further below > in the subtree, at which points the standard *VERSION* behavior is again > followed."), what I expect when versioning the node A is that D and E are > not copied, but it is not what I observe. I looked also in JCR 2.0 but > couldn't find anything explaining a different behavior. > What am I missing here? > > Thanks again for your patience, > > Davide > > > > On Mon, Mar 1, 2010 at 10:31 PM, Alexander Klimetschek > <[email protected]>wrote: > >> On Mon, Mar 1, 2010 at 22:28, Alexander Klimetschek <[email protected]> >> wrote: >> > Also it is optimized for trees >> > with fine-granular content (eg. a page in a CMS), not for arbitrary >> > sized subfolders with lots of binary content. >> >> Ah, forgot: have you tried your scenario with a FileDataStore? Using a >> datastore avoids duplicate binaries in the storage, so there should >> only be some overhead in hashing the files upon versioning. Not sure, >> it might be that the versioning implementation internally temporarily >> copies the files, which might be slow. >> >> Regards, >> Alex >> >> -- >> Alexander Klimetschek >> [email protected] >> >
