Re: [MirageOS-devel] Irmin merge question

[Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>]

> Yes, if the same object is changed then I get the callback. But this makes 
> the stat calculation difficult and dependent on the number of messages in the 
> mailbox.

I'm still unsure to understand your problem. Do you have a small reproducible 
code which exposes your problem? I'm keen to either fix the documentation or 
the bug if it happens to be a a problem in Irmin.

Thomas





> 
> Gregory
> 
>> On Aug 7, 2015, at 10:59 AM, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
>> 
>>> You are right. In this scenario there is nothing to update. But if we both 
>>> make changes then there is.
>> 
>> In that case the merge will not be a fast-forward and the merge callback 
>> should be called.
>> 
>> Thoma
>> 
>>> Even if we both just add files then the stats needs to be updated, for 
>>> instance the message count. So if I add m1, m2 and Bob adds m3,m4 then the 
>>> count in each database is 2 and 2 but the merged count is 4. This is an 
>>> easy case and the count can be derived from the updated objects, 
>>> specifically from the index, which is a list of UID to the message hash 
>>> map. But I have to search through all of the index to figure out what was 
>>> deleted/added so the time will increase as the number of messages 
>>> increases. But then there is other statistics like recent and unseen 
>>> messages, the first unseen message, and the next message UID. Some of them 
>>> are not easy to figure out. But if I get the changes in the custom merge 
>>> then figuring out this statistics is straightforward and the performance 
>>> doesnât depend on the number of messages in the mailbox.
>>> 
>>> Gregory
>>> 
>>>> On Aug 6, 2015, at 11:52 PM, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> 
>>>> wrote:
>>>> 
>>>>> I think it might be useful for setting different mailbox's merge 
>>>>> profiles. But it is definitely very helpful and easier in updating 
>>>>> mailboxâs overall statistics like message count, recent messages, etc. 
>>>>> Iâm actually not sure if I can use the changed objects only to derive 
>>>>> this statistics. The change to the API seems fairly small - it could be 
>>>>> an optional argument to the merge that indicates whether to use 
>>>>> âfast-forwardâ or not and set to true by default.
>>>> 
>>>> But I'm not sure to understand why a non fast-foward merge means.
>>>> 
>>>> ie, let's say your database is in state x. The Bob forks it. Then you do 
>>>> some operation, and you are in a state y. Then Bob wants to merge. The 
>>>> merge callback will be called with old=x, x and y. As Bob didn't do any 
>>>> operation, the merge result is simply y. There is no stats to update as 
>>>> Bob didn't do anything (otherwise it wouldn't have stayed in state x). Do 
>>>> you have a concrete scenario where you still have to update some stats 
>>>> even if Bob didn't do anything?
>>>> 
>>>> Thomas
>>>> 
>>>> 
>>>>> 
>>>>> Gregory
>>>>> 
>>>>>> On Aug 6, 2015, at 5:09 PM, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> 
>>>>>> wrote:
>>>>>> 
>>>>>>> As far as I can tell from the code, cases when lca=t1 or lca=t2 are 
>>>>>>> handled by the âdefault' method so the custom defined merge is not 
>>>>>>> called.
>>>>>>> But this was not always the case - in some revisions of ir_merge.ml the 
>>>>>>> âdefaultâ ( in method bijectâ ) was not called first :
>>>>>>> Commits on Mar 4,Feb 6, Feb 2 2015 - call âdefaultâ first
>>>>>>> Commits on Jan 27, Jan 26, Jan 12 2015 - donât call âdefaultâ first
>>>>>>> Commits on Jan 11 2015, and older - call âdefaultâ first
>>>>>> 
>>>>>> if the lca is the same as one of the 2 values then yes, we are now doing 
>>>>>> a "fast-forward" merge ie. we pick the most recent version (basically, 
>>>>>> that means that the other versions is late). Are you sure that you want 
>>>>>> to do a merge in that case?
>>>>>> 
>>>>>> Thomas
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> So it changed back and forth. I am not sure what the intention was but 
>>>>>>> I think having the ability to custom-handle all cases is preferred?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Gregory
>>>>>>> 
>>>>>>>> On Aug 5, 2015, at 11:45 PM, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> I have a question about Irmin merge call back for user-defined 
>>>>>>>>> contents. It appears that merge is only called for the content that 
>>>>>>>>> was changed but not added or deleted. Is it possible to have it 
>>>>>>>>> called for all actions?
>>>>>>>> 
>>>>>>>> It's supposed to be called even when one of the version is added or 
>>>>>>>> deleted. In that case one of the values will be a None. That's why the 
>>>>>>>> merge callback [1] takes an option type. Notice that you should not 
>>>>>>>> normally have None for all the 3 elements of the 3-way merge.
>>>>>>>> 
>>>>>>>> Best,
>>>>>>>> Thomas
>>>>>>>> 
>>>>>>>> [1] http://mirage.github.io/irmin/Irmin.Contents.S.html#VALmerge
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


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