On Tue, Apr 28, 2009 at 2:11 PM, Stefan Guggisberg <[email protected]> wrote: > Hi yoav, > > > > On 28.04.2009, at 01:51, Yoav Landman <[email protected]> wrote: > >> >> Hi, >> >> I am trying to understand the logic of merging mixing changes - >> I see that the NodeStateMerger is failing a merge due do a difference in >> the >> mixin type names. In practice, however, the content of the mixin type >> namesets is identical between the overlayed state and the modified state >> (same *names* references). But since the comparison of the 2 namesets >> themselves is done by reference (NameSet does not override equals()) and >> since the *namesets* references are different the merge ends up with a >> StaleItemStateException. >> >> My question is - >> Shouldn't the comparison of the mixin type sets be done by content, not by >> the references of the namesets themselves? > > Agreed, seems to be a bug. I'll have a look tomorrow and let you know.
this bug is a regression of [1]. the good news is that it has already been reported and fixed in trunk, see [2]. [1] https://issues.apache.org/jira/browse/JCR-1705 [2] https://issues.apache.org/jira/browse/JCR-2081 cheers stefan > >> The relevant comments in >> NodeStateMerger say: >> "the mixins have been modified but by just looking at the diff we can't >> determine where the change happened since the diffs of either removing a >> mixin from the overlayed or adding a mixin to the transient state would >> look >> identical..." >> I am trying to understand this and how it applies to the current behavior, >> but can't. Could someone shed some light on it? > > I guess the namesets are copied-on-write. The assumption therefore is that > non-equal nameset references mean that they've been modified. I'll have a > look. > > Cheers > Stefan > > >> >> >> Thanks, >> >> Yoav >> -- >> View this message in context: >> http://www.nabble.com/Understanding-mixins-merge-logic-tp23267598p23267598.html >> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com. >> >
