8.2.11.2 VERSION

Child Node

On checkin of N, the node VN will get a subnode of type nt:versionedChild with the same name as C. The single property of this node, jcr:childVersionHistory is a REFERENCE to the version history of C (not to C or any actual version of C). This also requires that C itself be versionable (otherwise it would not have a version history). 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.

NodeTypeName

nt:versionedChild

Supertypes

nt:base

IsMixin

false

HasOrderableChildNodes

false

PrimaryItemName

null

PropertyDefinition

Name jcr:childVersionHistory

RequiredType REFERENCE

ValueConstraints ["nt:versionHistory"]

DefaultValues null

AutoCreated true

Mandatory true

OnParentVersion ABORT

Protected true

Multiple false


On restore of VN, if the workspace currently has an already existing node corresponding to C’s version history and the removeExisting flag of the restore is set to true, then that instance of C becomes the child of the restored N.

If the workspace currently has an already existing node corresponding to C’s version history and the removeExisting flag of the restore is set to false then an ItemExistsException is thrown.

If the workspace does not have an instance of C then one is restored from C’s version history. The workspace in which the restore is being performed will determine which particular version of C will be restored. This determination depends on the configuration of the workspace and is outside the scope of this specification.

Property

In the case of properties, an OnParentVersion attribute of VERSION has the same effect as COPY.