Context

See the notes from UHZ for pain points and initial findings

The two main use cases for versioning are the ability to revert or recreate content changes on one hand and record keeping / archiving on the other. They differ in access pattern and retention policy:

• For reverting or recreating content changes we only need a couple recent versions but need to be able to access them quickly.
• For record keeping we need to be able to keep many versions for a long time. Such versions are mostly write only. Read access latency does not play a big role.

Questions for discovery

• How can we keep the version history in JCR tidy?
• Clean / archive in regular intervals or continuously? How do we make this transparent to the user?
• Can we offload versioning partially or entirely (e.g. to git)? What back end services should we support?
  • We could implement an archiving back-end: versions after a certain threshold would get removed from JCR and placed into the archive for record keeping. The archiving back-end would only support he record keeping use case and not the revert and recreate one.
  • Code from UZH: uzh-module-versioning.zip
• Removing, offloading or archiving versions will also help in keeping the repository lean resulting in e.g. better search performance
• Can we optimize the current versioning implementation?
  • Remove the extra workspace and all the copying to it
  • Rely on Jackrabbit versioning alone
  • Reduce synchronized code