Overview
Within Fedora 4, snapshots of the current state of a resource may be saved into the version history. The RDF for historic version shapshots may be browsed and old non-RDF content may be downloaded. Furthermore, an object or subgraph may be reverted to the state that it existed in a historic version.Creating versions
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 must provide a label that both serves to easily differentiate a version from another and allow 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 this feature.
Possible strategies include:
- For batch operations, only create version checkpoints once nodes have been ingested, verified and tested.
- For small (but high-level) data such as the descriptive metadata created by subject experts, set a versioning policy to store every modification, thereby capturing the entirety of the curatorial endeavor.
- Create snapshot versions that correspond to released versions of content (i.e., version X of a shared dataset, controlled vocabulary or collection)
Viewing old Versions
From the HTML view (or by issuing HTTP GET methods via an HTTP client program) you can get the version history of a node by appending "/fcr:versions" to it's base URL. Each version will be listed, with the version label as the title.
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, but you can view it, download non RDF-content or revert the resource or subraph to that version.
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 "Revert to this Version" exists, that when clicked restores the object (and possibly the sub-graph) to the version viewed.
When restoring an old version, two operations occur:
- Immediately before restoring the old version, a version snapshot is made to reflect the current state of the object. This version will not have a version label.
- The current state of the resource will be updated to match the version being restored – but a new version will not be created. You can create a version explicitly if you want to create a version that records the revert.
Deleting a previous version
If you wish to remove historic version snapshots you may do so either using the REST API or the HTML view of the historic version. You may not, however, delete the most recent version snapshot
14 Comments
Andrew Woods
Michael Durbin, It will be helpful to include sample REST calls as well as CND configurations.
Greg Jansen
Michael Durbin, does a version include child nodes all the way down? IOW is a version a snapshot of the tree or of the one node?
Michael Durbin
This is a good question Greg that likely exposes some shortcomings with our current versioning implementation and node type configuration.
It depends on the children. If a child is not versionable or has an "on parent version" property of "copy", that node and the entire subgraph is copied. A little testing has shown me that if you auto-generate an ID the placeholder nodes are not versionable, causing this copy to go into effect. If a child is versionable (like any fedora:resource in the default configuration) the spec says a special child with a reference to the version history of the child is supposed to be added.
http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.13.9%20Versionable%20State
Greg Jansen
It sounds as if versionable children would be more efficient, i.e. pointers instead of copies when the parent is versioned.. Being versionable without auto-versioning seems like a good thing.
Yinlin Chen
Can we see all the vision history in Web interface? I create several versions for a certain node and click fcr:versions link. It shows only two links, one root and a version. That version is not the latest created version.
Andrew Woods
Yes, all versions are in the web interface. If you do not see a specific version there, that means a specific version was not created (assuming there is not a bug). Can you describe the process by which you are "creating versions"?
Yinlin Chen
I can see all versions through command line:
curl -H "Accept: text/turtle" http://54.210.99.139:8080/fcrepo-webapp-4.0.0-beta-01/rest/test:3/fcr:versions
In Web GUI: I only see two: http://54.210.99.139:8080/fcrepo-webapp-4.0.0-beta-01/rest/test:3/fcr:versions
Create version command: curl -X POST http://54.210.99.139:8080/fcrepo-webapp-4.0.0-beta-01/rest/test:3/fcr:versions
Andrew Woods
Thanks, Yinlin Chen. I am seeing the same issue.
https://www.pivotaltracker.com/story/show/75910204
Justin Coyne
Is "version name" the same as "version label"? Both terms are used in this document and it's unclear what the difference is if any.
Andrew Woods
When I search for "name" in this document, I only come up with one result... which is not the same as a version label.
Are you seeing something else?
Justin Coyne
"When saving these versions you can optionally provide a label". This is not true after https://github.com/fcrepo4/fcrepo4/commit/5074ed63c30051cc1179eb688ce44ded95bafc54
Justin Coyne
Also the "Create a new version of an object" (without a name) example needs to be removed
Geetha
Hi,
I have a query in my usecase. Please help me to solve.
This is my scenario :
I have to do API versioning. I am using REST APIs with Restlet framework. I am confused how to implement the versioning in Java Source code.
If my API looks like this : http://localhost:8080/example.com/v2/hello
Then In my source code how to map the version with appropriate functionality?
For example :
If(version == 1) {//Do Version 1 Source Code}
else If(version == 2) {//Do Version 2 Source Code}
else If(version == 3) {//Do Version 3 Source Code} ………..
If I did like this, Then why we are going for Versioning. We can implement Manually Right? And also If I have to add some 100 versions, then the code looks uglier and it becomes lengthier.
I get confused how to map in Source Code. Please Clarify my doubt.
I have read that we can use annotations for handling API versioning. But I don't know what are the annotations available in restlet framework. Please let me know.
Regards,
Geetha.
Unknown User (escowles@ucsd.edu)
Geetha, this wiki page is documentation of versioning in the Fedora Repository, where versioning is used to store different states of repository content, not to separate different REST API versions.