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

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



>> 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?

Thomas

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


> 
> 
>> Thomas
>> 
>> [1]:  
>> https://github.com/mirage/ocaml-git/blob/master/lib/mirage/git_mirage.ml#L27
>> [2]: https://github.com/mirage/ocaml-git/pull/115
>> 
>> 
>>> 
>>> --
>>> Dr Thomas Leonard        http://roscidus.com/blog/
>>> GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA
>>> 
>>> _______________________________________________
>>> MirageOS-devel mailing list
>>> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>> 
> 
> 
> 
> -- 
> Dr Thomas Leonard        http://roscidus.com/blog/
> GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel


 


Rackspace

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