Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <50F53B39.2060505@apache.org>
Date: Tue, 15 Jan 2013 11:19:21 +0000
From: =?ISO-8859-1?Q?Michael_D=FCrig?= <mduerig@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: <oak-dev@jackrabbit.apache.org>
Subject: Re: MicroKernelIT#conflictingMove
References: 
 <9C0FC4C8E9C29945B01766FC7F9D3898173DA498CC@eurmbx01.eur.adobe.com>
In-Reply-To: 
 <9C0FC4C8E9C29945B01766FC7F9D3898173DA498CC@eurmbx01.eur.adobe.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit


On 15.1.13 10:23, Marcel Reutegger wrote:
>
>> I looked into why 2 tests failing in MicroKernelIT for MongoMK. One of
>> them is conflictingMove test. This test passes for MicroKernelImpl and it
>> looks like the reason is MicroKernelImpl always commits against head. Take
>> a look at CommitBuilder around line 112. There's a check whether baseRevId
>> is not equal to currentHead, and if so, the staged tree is reset to
>> currentHead and the operation is retried. This effectively means that the
>> operation is committed against head, right?
>
> hmm, not sure. I'd first have to look at the code. if it just blindly commits to
> head then it's certainly wrong and it also means it wouldn't detect the
> conflict, right? So, I guess what it does is some kind of rebase.

Yes, the H2 MK does some kind of rebase if the commit is not against the 
current head: it tries to reapply all changes against the current head 
an later tries to merge the resulting changes into trunk. However this 
results in a race condition. See 
https://issues.apache.org/jira/browse/OAK-532

>
>> We recently changed CommitCommand to commit against baseRevisionId
>> instead
>> of head but I'm thinking maybe we should change it back to committing
>> against head? Or maybe we commit against baseRevisionId but we add some
>> kind of a conflicting commit detection (although I'm not too sure how we'd
>> detect conflicting commits easily). WDYT?
>
> this is missing right now. merging with the *head* revision tree is done in
> CommitCommandNew.mergeNodes(). that is, mergeNodes() basically does
> the rebase I mentioned above. I recently added a FIXME to this method.
> I think this is the place where we'd need to find out if there is a conflict.
>

In a nutshell here is what I think we should do: MK.commit should fail 
on all but conflicts which are trivially merged. This will not be a 
problem for oak-core since oak-core applies changes to private branches 
and will merge these on Session.save. Before merging, branches are 
rebased and that's the place where the more complicated conflict 
handling should go. Due to rebasing the subsequent merge will not 
conflict any more.

See my POC work on https://issues.apache.org/jira/browse/OAK-536 for how 
such a rebase operation could look like. Note that the current 
implementation is not complete yet since it just throws an exception on 
conflicts. I will soon update this to a more complete implementation 
which correctly annotates conflicts such that oak-core can further 
handle these.

Also note how such an implementation will also solve OAK-464 and OAK-548.

Michael