jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Understanding mixins merge logic
Date Tue, 28 Apr 2009 12:11:55 GMT
Hi yoav,

On 28.04.2009, at 01:51, Yoav  Landman <ylandman@gmail.com> 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.

> 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.


> 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.

View raw message