Return-Path: X-Original-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BC3B19C25 for ; Tue, 3 Apr 2012 10:28:10 +0000 (UTC) Received: (qmail 88524 invoked by uid 500); 3 Apr 2012 10:28:10 -0000 Delivered-To: apmail-jackrabbit-oak-dev-archive@jackrabbit.apache.org Received: (qmail 88487 invoked by uid 500); 3 Apr 2012 10:28:10 -0000 Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: oak-dev@jackrabbit.apache.org Delivered-To: mailing list oak-dev@jackrabbit.apache.org Received: (qmail 88475 invoked by uid 99); 3 Apr 2012 10:28:10 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Apr 2012 10:28:10 +0000 X-ASF-Spam-Status: No, hits=-1.6 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [64.18.1.31] (HELO exprod6og113.obsmtp.com) (64.18.1.31) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Apr 2012 10:28:01 +0000 Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKT3rQm2Xemo+6kQKILmXCQvv7esC3JT1d@postini.com; Tue, 03 Apr 2012 03:27:40 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q33ARdv7020482 for ; Tue, 3 Apr 2012 03:27:39 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id q33ARc2a028630 for ; Tue, 3 Apr 2012 03:27:38 -0700 (PDT) Received: from eurcas01.eur.adobe.com (10.128.4.27) by nacas03.corp.adobe.com (10.8.189.121) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 3 Apr 2012 03:27:37 -0700 Received: from susi.local (10.136.133.122) by eurcas01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.192.1; Tue, 3 Apr 2012 11:27:37 +0100 Message-ID: <4F7AD098.4070809@apache.org> Date: Tue, 3 Apr 2012 11:27:36 +0100 From: =?ISO-8859-1?Q?Michael_D=FCrig?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Subject: Re: oak-api and move operations References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 3.4.12 11:20, Thomas Mueller wrote: > Hi, > >> I think there is some misunderstanding here. There is not more merging >> to be done by the Microkernel as it already does. Currently transient >> changes are kept in memory and passed to the Microkernel in a single >> commit call passing along a possible prohibitively large json diff. With >> the "private branch" approach, the transient changes are simple written >> ahead into a private branch and only on merge are these applied to the >> main branch. Think of it like a write ahead of the json diff to the >> Microkernel (although the implementation might differ). > > Currently, commit calls can be easily synchronized in the MicroKernel > implementation. If you want to achieve a similar isolation with branch() > and merge(), then a branch() would block other commits (and branch calls) > until the merge() call. I can't follow you here. Why would that be necessary? That would work I guess. One remaining problem is > then the ability to "undo" (rollback) a branch. I guess there should be a > method for that ("revert"). Why do we need a rollback? Access to the previous revision is still possible through the previous revision id. Another remaining problem is that each > MicroKernel implementation would need to support transactions that span > multiple calls (similar to 2-phase commits or transaction savepoints). Again why? Michael > > Regards, > Thomas >