[MirageOS-devel] Fwd: blog post on Irmin

[Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>]

I've accidentally made this replies directly to Malcom ... sharing them on the 
list as it could interest more people.

Thomas

> From: Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>
> Subject: Re: [MirageOS-devel] blog post on Irmin
> Date: 22 July 2014 11:35:02 BST
> To: Malcolm Matalka <mmatalka@xxxxxxxxx>
> 
> In some cases, doing 2-way merge is not possible (ex: distributed counters 
> where you represent them as int). In some cases, 2-way merge is not efficient 
> / not precise (ex: 2-way merge of files). But sometimes, it's good enough for 
> what you need and want (ex: CRDT where all what you need to do your merge is 
> in the state anyway). So I think it's good to let the user choose. What I'm 
> thinking currently (but this could change) is to make the ~old argument in 
> the 3-merge function lazy.
> 
> To come back to your initial question: if you have no information on the 
> context in which your are using the two concurrent values, yes you have a 
> conflict. But you can also know that you are adding values in a given record 
> of a  type t (the type t is the context). In this case, you can associate the 
> semantics you want to each field -- they can each have their own semantics 
> guarantees. For instance, you might want to store all updates in a set, and 
> the read always returns the full set, a semantics very close to amazon's 
> Dynamo: in Irmin terms, the merge function for that field will be just a set 
> union.
> 
> I plan to write a more detailed post on merges and conflicts in Irmin over 
> the summer.
> 
> Thomas
> 
> 
> 
> On 22 Jul 2014, at 09:55, Malcolm Matalka <mmatalka@xxxxxxxxx> wrote:
> 
>> Hrm, if someone has to be able to handle a 2-way merge anyways, then
>> doesn't that make the 3-way merge less useful?  If I can add/add any two
>> values then I need to be able to do 2 way resolution on any two values
>> anyways.
>> 
>> Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> writes:
>> 
>>>> In the blog post it says merge's are always done as a 3-way merge.  Does
>>>> that mean it's not possible to create the same key concurrently,
>>>> producing a situation where you have conflicting values but no 'old'
>>>> value?
>>> 
>>> By default, it is indeed the case. It is called an `add/add` conflict: see 
>>> https://github.com/mirage/irmin/blob/32e8dfde86d8cfd37173fc65aa7514f3a9b50c6a/lib/core/irminMerge.ml#L225
>>> 
>>> we plan to add some more limited 2-merge functions (to deal with such 
>>> cases) later on.
>>> 
>>> An other option is to defined your own custom data-type and wrap it in a 
>>> `'a option` type. You can then define your 3-merge function on 't option` 
>>> and specify what you want to have in that case.
>>> 
>>> --
>>> Thomas
>>> 
>>> 
>>>> 
>>>> Anil Madhavapeddy <anil@xxxxxxxxxx> writes:
>>>> 
>>>>> On 21 Jul 2014, at 01:43, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> For those who haven't seen it yet, we've published a blog post on Irmin 
>>>>>> last friday:
>>>>>> 
>>>>>> http://openmirage.org/blog/introducing-irmin
>>>>>> 
>>>>>> the thread on HN with interesting comments: 
>>>>>> https://news.ycombinator.com/item?id=8053687
>>>>>> 
>>>>> 
>>>>> And a followup just went live by Dave on his use of Irmin in Xenstore 
>>>>> (perhaps
>>>>> not the simplest one to start with, but hey, it's a pretty darn "real 
>>>>> world" use
>>>>> case).  Perhaps something more gentle like calendar sync next though :-)
>>>>> 
>>>>> http://openmirage.org/blog/introducing-irmin-in-xenstore
>>>>> 
>>>>> -anil
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> MirageOS-devel mailing list
>>>>> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
>>>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
> 


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