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

Re: [MirageOS-devel] Irmin merge question

You are right. In this scenario there is nothing to update. But if we both make 
changes then there is. 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.


> 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



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