Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of mueller@adobe.com designates
 64.18.1.78 as permitted sender)
From: Thomas Mueller <mueller@adobe.com>
To: "oak-dev@jackrabbit.apache.org" <oak-dev@jackrabbit.apache.org>
Date: Tue, 18 Dec 2012 15:34:32 +0000
Subject: Re: Conflict handling in Oak
Thread-Topic: Conflict handling in Oak
Thread-Index: Ac3dNSpE8WNo5uA4SbeJwCZeO7vweg==
Message-ID: <CCF64818.3906A%mueller@adobe.com>
In-Reply-To: <50D086D4.8030301@apache.org>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.2.5.121010
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi,

>>So, do "move" and "copy" operations need to be preserved, or can they be
>> converted to "add node" / "remove node"?
>
>Now we are getting somewhere: This is exactly the original topic of
>OAK-464. If the Microkernel converts moves to add/remove, implementing
>rebase on top of that results in moves of big sub trees to become *very*
>expensive.

As far as I know, in MongoDB, moves are implemented as "copy & delete", so
I don't think performance is a problem.

But I guess memory usage would be a problem if the whole subtree has to be
put in a Json document. MicroKernel.getJournal could lead to out of memory
for large move & copy operations, unless those operations are at least
somewhat preserved in the journal. As far as I understand, both
MicroKernel implementations do return move operations, so I guess it's not
a problem in practice(?)

Regards,
Thomas