Re: [MirageOS-devel] Irmin merge question

[Gregory Tsipenyuk <gt303@xxxxxxxxx>]

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.

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