A compliant content repository may support versioning. This feature allows the state of a node to be recorded in such a way that it can later be restored. The versioning system is modelled after the Workspace Versioning and Configuration Management (WVCM) API defined by JSR 147.
Whether a particular implementation supports versioning can be determined by querying the repository descriptor table with Repository.getDescriptor("OPTION_VERSIONING_SUPPORTED") (a return value of true indicates support for versioning, see 6.1.1.1 Repository Descriptors).
A versioning repository has, in addition to one or more workspaces, a special version storage area. The version storage consists of version histories. Versionable nodes in different workspaces share the same version history if and only if they have the same UUID (see 4.10.2 Multiple Workspaces and Corresponding Nodes).
A version history is a collection of versions connected to one another by the successor relationship. A new version is added to the version history of a versionable node when one of its workspace instances is checked-in. Every new version is attached to the version history as the successor of one (or more) of the existing versions. The result is that a version history is a directed acyclic graph of versions, where the arcs in the graph represent the successor relation.
The version storage objects are themselves defined as nodes. Though there is only one version storage per repository, the version storage data is reflected in each workspace as a special, protected, sub-tree of nodes of types nt:versionHistory and nt:version (see 8.2.2 Version Storage).
When a versionable node is checked-in (using Node.checkin) a new version is created in the version history of that node. The versionable node is also set to be read-only. In order to alter it with a regular write method, it must be checked-out (using Node.checkout). A versionable node can also be restored to the state recorded in one of its versions using Node.restore.