On Tue, Dec 18, 2012 at 2:55 PM, Michael Dürig <[email protected]> wrote: > > > On 18.12.12 12:35, Thomas Mueller wrote: >> >> Hi, >> >>> OTOH non conflicting changes could still lead to non commuting journal >>> entries and thus merging such changes would require journals to be >>> adjusted. >> >> >> Could you give an example? > > > Consider the revision you get after > > +/a:{} > +/x:{} > > on an initially empty tree. > > Now session 1 does > >>/a:/x/a > > and session 2 does > > -/a > > concurrently on that revision. > > The resulting trees could be merged by my first definition. However, the two > journal from session 1 and session 2 do not commute. You could neither do > >>/a:/x/a > -/a > > nor could you do > > -/a >>/a:/x/a > > That's why I included "If there are no other conflicts" referring to the > list of conflicts you gave earlier in my updated definition. With this the > resulting trees could not be merged at all in the first place. > > > Generally I think there are four ways to deal with this situation: > > 1) Make the definition of conflicts sufficiently strong to exclude such > cases. That's Tom's proposal from this Thread. > > 2) Allow inconsistent journals.
-1, i consider that a bug > > 3) Adjust the journals to reflect the changes introduced through merges. irrelevant since the journal is expected to be consistent > > 4) Drop journal support. -1, i fail to see why that would be required. cheers stefan > > Michael > > >> >> Regards, >> Thomas >> >
