|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] Irmin merge question
Sure, the tar contains sync.ml , ex1.sh, and two repoâs:repor and repol. repor contains a,a1,a2 and repol contains a,a3,a4. âaâ has been edited in both repoâs; a1,a2 added to repor only; a3,a4 added to repol only. Unpack the archive and run ex1.sh. The callback will be only called for âaâ and not for a1,a2,a3,a4 Attachment:
repo.tar.gz Thanks, Gregory > On Aug 7, 2015, at 1:53 PM, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote: > >> 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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |