To be versionable, a node must have mix:versionable as one of its mixin node types. Recall from 6.7.21.3 mix:versionable, that this node type has the following definition:
NodeTypeName
mix:versionable
Supertypes
mix:referenceable
IsMixin
true
HasOrderableChildNodes
false
PrimaryItemName
null
PropertyDefinition
Name jcr:versionHistory
RequiredType REFERENCE
ValueConstraints ["nt:versionHistory"]
DefaultValues null
AutoCreated false
Mandatory true
OnParentVersion COPY
Protected true
Multiple false
PropertyDefinition
Name jcr:baseVersion
RequiredType REFERENCE
ValueConstraints ["nt:version"]
DefaultValues null
AutoCreated false
Mandatory true
OnParentVersion IGNORE
Protected true
Multiple false
PropertyDefinition
Name jcr:isCheckedOut
RequiredType BOOLEAN
ValueConstraints []
DefaultValues [true]
AutoCreated true
Mandatory true
OnParentVersion IGNORE
Protected true
Multiple false
PropertyDefinition
Name jcr:predecessors
RequiredType REFERENCE
ValueConstraints [nt:version]
DefaultValues null
AutoCreated false
Mandatory true
OnParentVersion COPY
Protected true
Multiple true
PropertyDefinition
Name jcr:mergeFailed
RequiredType REFERENCE
ValueConstraints []
DefaultValues null
AutoCreated false
Mandatory false
OnParentVersion ABORT
Protected true
Multiple true
As the definition indicates, mix:versionable is a subtype of mix:referenceable which mandates the property jcr:uuid, exposing a universally unique identifier for the node (see 6.7.21.2, mix:referenceable). The result is that all versionable nodes are guaranteed to have a UUID.
In addition to this inherited property, a mix:versionable node has the properties jcr:versionHistory, jcr:baseVersion, jcr:isCheckedOut, jcr:predecessors and jcr:mergeFailed.
jcr:versionHistory is a REFERENCE property which points to the nt:versionHistory node that holds as its children the nt:version nodes that make up this versionable node’s version history. Note that the UUID of the nt:versionHistory node is different from the UUID shared by the set of corresponding versionable nodes (at most one per workspace) that it serves.
jcr:baseVersion is also a REFERENCE property. It points to the current base version of this node. The base version is one of the nt:version nodes within the version history pointed to by jcr:versionHistory, above. The base version (like all versions) is an nt:version node, and this property stores the UUID of that node. Again, the UUID of the version node is different from that shared by the set of corresponding versionable nodes in the workspaces, and from all other version nodes.
jcr:isCheckedOut is a BOOLEAN property that records whether this versionable node is checked-out or checked-in. When a versionable node is in the checked-in state, it is read-only, and cannot be altered by the regular write methods of the API. Note that this status is distinct from the node type-enforced protected status. When a versionable node is checked-out it can (if it is not protected) be altered by the API write methods. The checked-out status provides an indicator to other sessions on the same workspace telling them when a particular versionable node is “being worked on”. The read-only status enforced when a versionable node is checked-in propagates to all its non-versionable descendants. When a versionable node is checked in, it and its non-versionable subtree become read-only; when it is checked-out, it and its non-versionable subtree lose their read-only status.
jcr:predecessors is a multi-value REFERENCE property that points to one or more versions within the version graph of the version history pointed by jcr:versionHistory. These versions are those that are currently scheduled to become the predecessors of this versionable node when it is checked-in (and recorded in a version of its own).
jcr:mergeFailed is a multi-value REFERENCE property that is used in the context of the merge method. A merge compares the base version of this versionable node with the base version of its corresponding node in some other workspace. If the system can determine which base version is a successor of the other, then it either leaves this versionable node alone (if this node's base version is the successor of the other node's base version) or updates it to reflect the corresponding node (if the corresponding node's base version is a successor of this node's base version). In cases where the system cannot determine which node is the successor, the merge is said to “fail”. When that happens, a reference to the base version of the corresponding node in the other workspace is added to this node's jcr:mergeFailed property, thus keeping a record of which nodes could not be merged, and therefore allowing the application to deal with these nodes appropriately. See 8.2.10 Merge, for more details.
All of these properties that store the versioning-related meta-data are protected (though of course the versionable node itself, and its other application-specific subitems may or may not be protected). This guarantees that the client cannot alter the meta-data values; they are maintained by the repository implementation itself.