Re: [MirageOS-devel] Irmin merge question

[Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>]

> 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