Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of stefan.guggisberg@gmail.com
 designates 209.85.214.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50D06FE5.9070107@gmail.com>
References: <50C8A6CD.6070809@apache.org>
	<CAFYk8NmqmSDH0BLnFAczYLqHqnjQ3VPM2O9CnGHMf315ahFN-w@mail.gmail.com>
	<50D06FE5.9070107@gmail.com>
Date: Tue, 18 Dec 2012 14:39:22 +0100
Message-ID: 
 <CAFYk8Nk46G7_TYu=Qr-+YqS8q7GnSuWJ89vZeDjWU8a1POiK7g@mail.gmail.com>
Subject: Re: Conflict handling in Oak
From: Stefan Guggisberg <stefan.guggisberg@gmail.com>
To: "oak-dev@jackrabbit.apache.org" <oak-dev@jackrabbit.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 18, 2012 at 2:30 PM, Michael D=FCrig <michid@gmail.com> wrote:
>
>
> On 18.12.12 11:30, Stefan Guggisberg wrote:
>>
>> On Wed, Dec 12, 2012 at 4:46 PM, Michael D=FCrig <mduerig@apache.org> wr=
ote:
>>>
>>> Hi,
>>>
>>> Currently the Microkernel contract does not specify a merge policy but =
is
>>> free to try to merge conflicting changes or throw an exception. I think
>>> this
>>> is problematic in various ways:
>>>
>>> 1) Automatic merging may violate the principal of least surprise. It ca=
n
>>> be
>>> arbitrary complex and still be incorrect wrt. different use cases which
>>> need
>>> different merge strategies for the same conflict.
>>>
>>> 2) Furthermore merges should be correctly mirrored in the journal.
>>> According
>>> to the Microkernel API: "deleting a node is allowed if the node existed
>>> in
>>> the given revision, even if it was deleted in the meantime." So the
>>> following should currently not fail (it does though, see OAK-507):
>>>
>>>      String base =3D mk.getHeadRevision();
>>>      String r1 =3D mk.commit("-a", base)
>>>      String r2 =3D mk.commit("-a", base)
>>>
>>> At this point retrieving the journal up to revision r2 should only
>>> contain a
>>> single -a operation. I'm quite sure this is currently not the case and
>>> the
>>> journal will contain two -a operations. One for revision r1 and another
>>> for
>>> revision r2.
>>
>>
>> if that's the case then it's a bug. the journal must IMO contain the exa=
ct
>> diff
>> from a revision to its predecessor.
>
>
> See OAK-532.

thanks
stefan

>
> Michael
>
>
>>
>> cheers
>> stefan
>>
>>>
>>> 3) Throwing an unspecific MicrokernelException leaves the API consumer
>>> with
>>> no clue on what caused a commit to fail. Retrying a commit after some
>>> client
>>> side conflict resolution becomes a hit and miss. See OAK-442.
>>>
>>>
>>> To address 1) I suggest we define a set of clear cut cases where any
>>> Microkernel implementations MUST merge. For the other cases I'm not sur=
e
>>> whether we should make them MUST NOT, SHOULD NOT or MAY merge.
>>>
>>> To address 2) My preferred solution would be to drop getJournal entirel=
y
>>> from the Microkernel API. However, this means rebasing a branch would
>>> need
>>> to go into the Microkernel (OAK-464). Otherwise every merge defined for
>>> 1)
>>> would need to take care the journal is adjusted accordingly.
>>> Another possibility here is to leave the journal unadjusted. However th=
en
>>> we
>>> need to specify MUST NOT for other merges in 1). Because only then can
>>> clients of the journal know how to interpret the journal (receptively t=
he
>>> conflicts contained therein).
>>>
>>> To address 3) I'd simply derive a more specific exception from
>>> MicroKernelException and throw that in the case of a conflict. See
>>> OAK-496.
>>>
>>> Michael