From NSDLWiki

Community:OnFire | OnFire 1.1 | Design 1.1 | Features 1.1 | Status 1.1

Versioning: Initial Analysis

The major issues related to versioning are:

• Versioning of Uploaded Content
• Versioning of Entire Record
• Revert to Previous Version

Versioning of Uploaded Content

Currently, if updates need to be made to uploaded content, the uploaded content must be removed from the Fez record. This deletes the underlying datastream. Then the new version of the content is uploaded creating a new datastream to hold the new version. Previous versions of the uploaded content no longer exist. The same is true for external references.

To address this limitation, I propose that datastream versioning be used for uploaded content. My initial take on the design of the versioning system follows.

Currently, when the user selects the edit icon for a record, the attached files and related links are listed at the bottom. See Sample UI for Versioning to see proposed changes to this area to allow for updating with a new version. (I didn't take the time to resolve all css issues, but you'll get the basic idea.)

In Fedora 2.1, I would use the upload process to get the new version of the file into fedora and then call modifyDatastreamByReference passing the internal URI returned from the upload process as the location. I believe that Fedora 2.2 supports uploading as part of the modifyDatastreamByReference call, but I haven't done anything with 2.2 yet, so I don't know that for sure. The only trick is that the mimetype of the new file must be compatible with the mimetype of the existing file. For example, you can replace an image with another image, but you cannot replace an image with a text file.

Versioning of Entire Record

This section addresses how to provide the user access to previous versions of a record?

Currently, all datastreams are versioned except the aforementioned uploaded documents and links to external resources. With the addition of the Datastream Versioning of Uploaded Content (described above), all datastreams will be versioned.

Fedora handles the request for a specific version of a datastream by receiving a date with API calls. The latest value for the datastream preceding and/or including that date is returned from Fedora.

In Fez, at publish time, a snapshot of the status of the record would be recorded as part of the history by including the date-time stamp of the publish action. In Fez, the Detailed History screen could be updated to include a link to View Record that would also pass the date-time stamp to allow values from the date associated with the selected history entry to be viewed.

Required changes:

• Detailed History would need to include links to View Record passing the date-time stamp.
• View Record would need to be able to display any version of a record based on the date-time stamp.
• Methods to fill in the details object would need to be updated to allow a date to be specified.

Revert to Previous Version

How would revert to a previous version be implemented? Would Detailed History provide this ability? Or would View Record provide this ability?

Either way, to do the Revert to Previous Version, the values of the selected previous version would be copied and saved, making it the latest version. All versions would be retained.

Example,
In this example, before the revert action three versions exist... A B C. If reverting to version B, the versions will be A B C B'. Thus A, B, and C are retained, and a new copy of B becomes the latest version.