Overview
Within Fedora 4, snapshots of the current state of an object may be saved into the version history either through explicit user requests or during each update to that object. The properties or content of a node saved in these version checkpoints may be accessed later to serve as a historical record of the object. Future feature development may allow for easy reversion to prior versions, export of the entire history or other useful actions.Enabling Versioning
By default, versioning is disabled for all nodes. In order to enable version-related operations for a node, you must first add the mix:versionable
mixin.
To enable versioning for a single node using the REST API:
echo "insert data { <> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.jcp.org/jcr/mix/1.0versionable> . }" \ | curl -X PATCH --upload-file - http://localhost:8080/rest/path/to/object
Enabling versioning for all nodes is incompatible with read/write filesystem federation. If you are not using filesystem federation (or only read-only), you can make all nodes versionable by default.
Creating versions
Explicit version creation
When you wish to save a snapshot of the current version of a node to the version history you can use the REST API. When saving these versions you can optionally provide a label that both serves to easily differentiate a version from another and allows easy retrieval of that version.
Duplicate Version Labels
Version creation is a relatively costly operation. With the ability to create versions whenever you wish, you can develop workflows that maximize the utility of the version history.
Possible strategies include:
- For batch operations, only create version checkpoints once nodes have been ingested, verified and tested.
- For high value but small data such as descriptive metadata entered by subject experts, set a versioning policy to store every modification to capture the entirety of the curatorial endeavor.
- Create snapshot versions that correspond to released versions of content (ie, version X of a shared dataset, controlled vocabulary or collection)
Implicit version creation
If you wish to save a full history of a node by having versions created every time the node is updated, you can set the property "fedoraconfig:versioningPolicy" to "auto-version". This can be achieved using the sparql update form on the HTML view of the object or by using some other HTTP client software to invoke REST endpoints.
PREFIX fedoraconfig: <http://fedora.info/definitions/v4/config#> INSERT { <> fedoraconfig:versioningPolicy "auto-version" }
If your needs for digital preservation are highest and you're willing to sacrifice a little bit of performance, you can set up repository-wide automatic versioning.
Viewing old Versions
From the HTML view (or by issuing HTTP GET methods in an HTTP client program) you can get the version history of a node by appending "/fcr:versions" to it's base URL. The root version will always be listed and represents the object at inception. Following the root version will be any other versions created. When labels have been specified, those labels will be displayed, otherwise the version will be identified by the modification date.
Previewing historic properties
By clicking on the box for a version you can expand and collapse a view of the version properties.
Navigating to the full view of an historic version
By clicking on the label of a version in the version listing you will be taken to the stored version of that resource. Because it's part of the historic record, you cannot edit it and certain properties have been stored in different property names (mixin types, uuid) but you can export that snapshot or view any content.
Reverting to a previous version
If you wish to restore an object to a previous version you may do so using the REST API, or even the HTML view. In the HTML view of a historic version, a button exists on the right hand side saying "Revert to this Version" that when clicked restores the object (and possibly the subgraph) to the version viewed.
Regardless of your auto-versioning settings immediately before restoring an old version, a version snapshot is made to reflect the current state of the object.