[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] Irmin-on-Mirage status

On 14 August 2015 at 14:14, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
>>> Yes, I've started to make one for ocaml-git[1]. Should be the same 
>>> signature that Irmin_fs.IO (or at least not very far).
>>> I'm refactoring ocaml-git to be able to change the SHA implementation more 
>>> easily. So it's now possible to use a pure-OCaml implementation when 
>>> compiling to javascript (instead of unconditionally depend on nocrypto) so 
>>> you can use it in Cuepkeeper to be compatible with Git. The branch is 
>>> almost ready to merge, I'm fixing some last issues with make `ogit fetch` 
>>> work optimally.
>> That sounds useful! I'm looking at updating irmin-indexeddb to use the
>> Git format now. It looks like there are two ways I could do this:
>> 1. Implement Git.FS.IO for IndexedDB and let ocaml-git use this
>> virtual filesystem. Then implement Git.Sync.IO and Irmin_git.LOCK and
>> use that with Irmin_git.FS.
>> 2. Expose Irmin_git.XContents, XCommit and XNode and use that with 
>> Irmin.Make.
>> The first looks a bit ugly, especially regarding locking. It would
>> involve cross-tab notifications using HTML storage, atomic operations
>> using IndexedDB and some recovery mechanism for dealing with closed
>> tabs. All of which seems like overkill, since Irmin_git would only use
>> these primitives to implement database transactions, which we have
>> already (e.g. we'd be using a database transaction to create a
>> lock-file to protect a Git transaction).
>> So, does exposing Irmin_git.XContents, XCommit and XNode sound
>> reasonable? Irmin-IndexedDB would still be writing directly to the
>> "ao" database table as before, but the blobs would be in Git format,
>> so the SHA1 sums would match, and it should then be possible to sync
>> between the browser and a regular Git repository without rebasing
>> everything.
> We indeed need to expose something else to make that logic easier. I think 
> the simplest way would be to expose a functor in Git.Memory[1] for storing 
> inflated values -- currently we are simply using in-memory Hashtbl, but that 
> could be made a bit more abstract. Using that functor you can them have an 
> Git.Store.S that you can pass to Irmin. What do you think?

That's possible, but the main problem is that the Irmin functor
requires Git.Sync.IO, Git.FS.IO and LOCK, none of which I want to
implement in the browser.

I have an experimental branch here that stores the contents/blobs in
Git format, but (currently) nodes/trees and commits in Irmin format:


I also need a scheme to upgrade from the old format to the new one. I
have a test script (test.html) in that repository that tries an
upgrade (but fails, because it's not implemented yet).

> Thomas
> [1]: https://github.com/mirage/ocaml-git/blob/master/lib/memory.ml#L34

Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.