Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Tip

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. 

Code Block
PREFIX fedoraconfig: <http://fedora.info/definitions/v4/config#>
INSERT { <> fedoraconfig:versioningPolicy "auto-version" }
Tip

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. 

...