Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <23293466.post@talk.nabble.com>
Date: Wed, 29 Apr 2009 02:13:18 -0700 (PDT)
From: Yoav  Landman <ylandman@gmail.com>
To: dev@jackrabbit.apache.org
Subject: Re: Understanding mixins merge logic
In-Reply-To: <90a8d1c00904290133g3e23fe17h8fdb64544ed3b2fd@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
References: <23267598.post@talk.nabble.com>
 <923C3657-7986-432A-A2AE-697724108524@gmail.com>
 <90a8d1c00904290133g3e23fe17h8fdb64544ed3b2fd@mail.gmail.com>


Missed that new jira somehow. Great - thank you!

Yoav


Stefan Guggisberg wrote:
>=20
> On Tue, Apr 28, 2009 at 2:11 PM, Stefan Guggisberg
> <stefan.guggisberg@gmail.com> wrote:
>> Hi yoav,
>>
>>
>>
>> On 28.04.2009, at 01:51, Yoav =C2=A0Landman <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 i=
n
>>> the
>>> mixin type names. In practice, however, the content of the mixin type
>>> namesets is identical between the overlayed state and the modified stat=
e
>>> (same *names* references). But since the comparison of the 2 namesets
>>> themselves is done by reference (NameSet does not override equals()) an=
d
>>> 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.
>=20
> this bug is a regression of [1]. the good news is that it has already bee=
n
> reported and fixed in trunk, see [2].
>=20
> [1] https://issues.apache.org/jira/browse/JCR-1705
> [2] https://issues.apache.org/jira/browse/JCR-2081
>=20
> cheers
> stefan
>=20
>>
>>> 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
>> =C2=A0non-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-tp23267598p23267=
598.html
>>> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
>>>
>>
>=20
>=20

--=20
View this message in context: http://www.nabble.com/Understanding-mixins-me=
rge-logic-tp23267598p23293466.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.