Hacker News new | past | comments | ask | show | jobs | submit login

This article reads very much like how git-annex works to me, except that while git-annex is built on top of git (and consequently works at a much higher level), Irmin sounds like it does pretty much the same thing but at a much lower level.

In other words, I think I could implement what's being described as a very thin shim on top of git-annex. You'd just need a special git merge driver (the same as Irmin, which requires 3-way merge providers), but with the extra caveat that all three components of the merge have to be present in the local annex before a merge can take place.

This is just based on the article, and assumes I've understood correctly.

Is this accurate?




That's a reasonable way to think about it, except that Git is just one backend option in Irmin, whereas git-annex is obviously specialized for git (and does it very well, too). The Irmin in-memory store, for example, never actually serializes into Git (and so is faster for IPC).

There are some interesting tricks going on from the native Irmin representation to the Git conversion (which is slightly less descriptive than Irmin and so virtual nodes are constructed to represent the extra data in Git). Will write that up in more detail in a future post I think, but for now:

https://github.com/mirage/irmin/blob/master/lib/backend/irmi... https://github.com/mirage/irmin/blob/master/lib/backend/irmi...

(is the Git serializer, and you can see in the interface how you can spawn an on-disk and in-memory Git).

and the simpler in-memory backend:

https://github.com/mirage/irmin/blob/master/lib/backend/irmi... https://github.com/mirage/irmin/blob/master/lib/backend/irmi...

where the implementation is mostly a noop since no mappings between representations needs to take place.

(Edited to note:) The reason for wanting an in-memory backend in the first place is that this is also very useful for IPC coordination. You could build a session layer where all the messages that go back-and-forth between two processes are recorded into an in-memory layer, and then when the whole process is done, the entire graph of communication can be dumped out to a Git tree as the log (for later analytics or debugging). If disk space is an issue, the Git tree can later be rebased to eliminate the intermediate communication commits. This is very, very useful for debugging.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: