Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Add some images #188

Merged
merged 1 commit into from

2 participants

@samoht
Owner

No description provided.

@avsm avsm merged commit fa810d6 into mirage:master
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jul 18, 2014
  1. @samoht

    Add some images

    samoht authored
This page is out of date. Refresh to see the latest.
View
BIN  files/graphics/irmin-merge.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN  files/graphics/irmin-stores.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
14 tmpl/blog/introducing-irmin.md
@@ -53,7 +53,7 @@ Irmin focuses on two main aspects:
verify.
* **Complexity**: how to design efficient merge and synchronization
-primitives, taking advantage of the immutable nature of the underlying
+primitives, taking advantage of the immutable nature of the underlying
objects.
Although it is pervasively used, *data persistence* has a very broad and
@@ -91,7 +91,7 @@ block stores a lot of nice properties and greatly simplify the way distributed
stores can be synchronized.
*Persistent* data structures are immutable, and once a block is created in
-the block store, its contents will never change again.
+the block store, its contents will never change again.
Updating an immutable data structure means returning a completely new
structure, while trying to share common sub-parts to avoid the cost of
making new allocations as much as possible. For instance, modifying a
@@ -138,13 +138,15 @@ one. This style of programming is appealing when implementing complex
However, this makes sharing information between processes much more
difficult, as you need a way to "inject" the state of one structure in an
other processes memory. In order to do so, Irmin borrows the concept of
-*branches* from Git by relating every operation to a branch name, and
+*branches* from Git by relating every operation to a branch name, and
modifying the tip of the branch if it has side-effects.
-The Irmin *tag store* is the only mutable part of the whole system and
+The Irmin *tag store* is the only mutable part of the whole system and
is responsible for mapping some global (branch) names to blocks in the
block store. These tag names can then be used to pass block references between
different processes.
+<img src="/graphics/irmin-stores.png" alt="Irmin Stores" />
+
A block store and a tag store can be combined to build
a higher-level store (the Irmin store) with fine concurrency control
and atomicity guarantees. As mutation happens only in the tag store,
@@ -200,7 +202,7 @@ nice, but in practice it has two major drawbacks:
* It does not specify how we find the initial state from two diverging
states -- this is generally not possible (think of diverging
counters); and
-* It means we need to compute the sequence of `update` operations
+* It means we need to compute the sequence of `update` operations
that leads from one state to an other. This is easier than finding
the common initial state between two branches, but is still generally
not very efficient.
@@ -218,6 +220,8 @@ contains the list of its predecessors as well as the actual data it
associated to. As it is purely functional, we can (and we do) store
that graph in an Irmin block store.
+<img src="/graphics/irmin-merges.png" alt="Finding a common ancestor" />
+
Having a persistent and immutable history is good for various obvious
reasons, such as access to a forensics if an error occurs or
snapshot and rollback features for free. But another less obvious
Something went wrong with that request. Please try again.