Hi!

 Glad to hear! Mutable HEAD means that it is up to the application to "record" a version. I'm not a big fan of it, I prefer to work with application transaction where the application itself keep a transaction where multiple operations are performed and then commited once. So you record a version after all went well and without version inflation. MH is something that should live short in time, so should be implemented in the application's single operation lifecycle. That means that you can use it as a transaction but you've to implement your own rollback. For example, a user start to modify an objects, MH get updated and then the users stop or the software return an error, or another user want to update the object, and a MH lays around and nobody don't know what to do. MH are good in a workflow when you've a single agent that update your object in a predictable manner and then commit (or discard) when all is done, while preserving the MH object. It is like to have OCFL inside OCFL, with revisions instead of versions, and the extension documentation say that it must short in time but this does not happen in the real world. Transactions can be risky for long running operations because they are usually associated with a timeout, then you've to implement some sort of timeout update trigger or continue and then monitor the long running operation outside the transaction while MH don't have this issue.

OCFL 2.0 is said that it will enable merging of versions (https://www.youtube.com/watch?si=lW5Q3GNqgVY7AJkn&t=1252&v=cI762HC9PAQ&feature=youtu.be) but I don't see it in the milestone (https://github.com/OCFL/Use-Cases/milestone/2) so it is not clear if it will be implemented. I think these are application feature, and consistency can be tricky. I prefer versioning + transactions that offer the best with low risks or complications (other than very long running operations).

CAUTION: This e-mail originated outside the University of Southampton.

CAUTION: This e-mail originated outside the University of Southampton.

Hi Yuri,

No solution from me (sorry), but I would also be interested in this.

I think OCFL, with the 'Mutable HEAD' extension (https://ocfl.github.io/extensions/0005-mutable-head.html) could be used as an EPrints Storage plugin, allowing content and revision XML to be stored alongside the content.

It may also be possible to put some usage stats in there too, although with the current volume of hits I'm not sure whether this is a sensible idea or not!

Cheers,

John

---

From: eprints-tech-request@ecs.soton.ac.uk <eprints-tech-request@ecs.soton.ac.uk> on behalf of Yuri <yurj@alfa.it>
Sent: Tuesday, July 21, 2026 07:16
To: EPrints.org Technical List <eprints-tech@ecs.soton.ac.uk>
Subject: [EP-tech] EPrints and OCFL

CAUTION: External Message. Use caution opening links and attachments.

CAUTION: This e-mail originated outside the University of Southampton.

CAUTION: This e-mail originated outside the University of Southampton.

Hi!

  I'm managing an archive which uses OCFL as low level storage. I like
it very much, it is a standard, preservation oriented, support
extensions and backward compatibility. I would like to hear if EPrints
are planning to implement it in the future, at least as an import/export
format. I see there's no specific Perl implementation of OCFL.

*** Options: https://wiki.eprints.org/w/Eprints-tech_Mailing_List
*** Archive: https://www.eprints.org/tech.php/
*** EPrints community wiki: https://wiki.eprints.org/