Legend:
Library
Module
Module type
Parameter
Class
Class type
type hash
Irmin stores
Irmin stores are tree-like read-write stores with extended capabilities. They allow an application (or a collection of applications) to work with multiple local states, which can be forked and merged programmatically, without having to rely on a global state. In a way very similar to version control systems, Irmin local states are called branches.
There are two kinds of store in Irmin: the ones based on persistent named branches and the ones based temporary detached heads. These exist relative to a local, larger (and shared) store, and have some (shared) contents. This is exactly the same as usual version control systems, that the informed user can see as an implicit purely functional data-structure.
of_commit c is a temporary store, based on the commit c.
Temporary stores do not have stable names: instead they can be addressed using the hash of the current commit. Temporary stores are similar to Git's detached heads. In a temporary store, all the operations are performed relative to the current head and update operations can modify the current head: the current stores's head will automatically become the new head obtained after performing the update.
with_tree t k ~info f replaces atomically the subtree v under k in the store t by the contents of the tree f v, using the commit info info ().
If v = f v and allow_empty is unset (default) then, the operation is a no-op.
If v != f v and no other changes happen concurrently, f v becomes the new subtree under k. If other changes happen concurrently to that operations, the semantics depend on the value of strategy:
if strategy = `Set, use set and discard any concurrent updates to k.
if strategy = `Test_and_set (default), use test_and_set and ensure that no concurrent operations are updating k.
if strategy = `Merge, use merge and ensure that concurrent updates and merged with the values present at the beginning of the transaction.
Note: Irmin transactions provides snapshot isolation guarantees: reads and writes are isolated in every transaction, but only write conflicts are visible on commit.
watch t f calls f every time the contents of t's head is updated.
Note: even if f might skip some head updates, it will never be called concurrently: all consecutive calls to f are done in sequence, so we ensure that the previous one ended before calling the next one.
merge_into ~into i t merges t's current branch into x's current branch using the info i. After that operation, the two stores are still independent. Similar to git merge <branch>.
val history :
?depth:int ->?min:commit list->?max:commit list->t->History.t Lwt.t
history ?depth ?min ?max t is a view of the history of the store t, of depth at most depth, starting from the t's head (or from max if the head is not set) and stopping at min if specified.
val last_modified : ?depth:int ->?n:int ->t->path->commit listLwt.t
last_modified ?number c k is the list of the last number commits that modified path, in ascending order of date. depth is the maximum depth to be explored in the commit graph, if any. Default value for number is 1.