Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of tripod@day.com designates
 207.126.148.89 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <8ea1ff9e1003031302t343ebae8n404dca7073de580c@mail.gmail.com>
References: <8ea1ff9e1003011031i71527587qd8a5e327292ad2b0@mail.gmail.com>
	 <c3ac3bad1003011328u12732ae8v33a092d474212f1a@mail.gmail.com>
	 <c3ac3bad1003011331xb4cbf63hd5575161d6894946@mail.gmail.com>
	 <8ea1ff9e1003031302t343ebae8n404dca7073de580c@mail.gmail.com>
Date: Fri, 26 Mar 2010 14:05:11 +0100
Message-ID: <ffd6aaa91003260605u3cbd6319vcf5a44e51ee50658@mail.gmail.com>
Subject: Re: Recursive child versioning
From: Tobias Bocanegra <tripod@day.com>
To: users@jackrabbit.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

hi,
that is not entirely true.

if you checkin A, then B (and the entire subtree is copied, since B is
not versionable (irrespective of the OPV of B).

3.13.9 Versionable State
[...]
5. For each child node C of N where
=95	C has an OPV of COPY,
a copy of the entire subgraph rooted at C (regardless of the OPV
values of the sub-items) is added to the frozen node, preserving the
name of C and the names and values of all its sub-items.
[...]

if you checkin B, then all C's should be not copied if they have a OPV=3DVE=
RSION:

3.13.9 Versionable State
[...]
6. For each child node C of N where:
=95	C has an OPV of VERSION
Under simple versioning, the same behavior as COPY. Under full
versioning, if C is not mix:versionable, the same behavior as
COPY.
Under full versioning, if C is mix:versionable, then a special
nt:versionedChild node with a reference to the version history of C is
substituted in place of C as a child of the frozen node.
[...]

So you statement:
"... however the recursive copy terminates at each versionable node
encountered further below in the subtree, "

is not correct. where did you read this?
regards, toby


On Wed, Mar 3, 2010 at 10:02 PM, Davide Maestroni
<davide.maestroni@gmail.com> wrote:
> Hi Alex,
>
> thank you for your suggestions, now I have a clearer idea about the
> versioning of child nodes.
> Though I still have one doubt. In my repository I have a parent-child
> structure like this:
>
> A (mix:versionable, nt:unstructured)
> =A0 =A0 =A0^
> =A0 =A0 =A0|
> B (nt:unstructured)
> =A0 =A0 =A0^
> =A0 =A0 =A0|
> C (mix:versionable, nt:unstructured)
> =A0 =A0 =A0^
> =A0 =A0 =A0|
> D (nt:file)
> =A0 =A0 =A0^
> =A0 =A0 =A0|
> E (nt:resource)
>
> Where the OnParentVersion attribute for child nodes, in the node type
> definition of A, B and C, is always VERSION.
> As per what written in paragraph 8.2.11.2 of JCR 1.0 specifications ("If =
*C* is
> not versionable then the behavior of *COPY*applies on *checkin*, however =
the
> recursive copy terminates at each versionable node encountered further be=
low
> in the subtree, at which points the standard *VERSION* behavior is again
> followed."), what I expect when versioning the node A is that D and E are
> not copied, but it is not what I observe. I looked also in JCR 2.0 but
> couldn't find anything explaining a different behavior.
> What am I missing here?
>
> Thanks again for your patience,
>
> Davide
>
>
>
> On Mon, Mar 1, 2010 at 10:31 PM, Alexander Klimetschek <aklimets@day.com>=
wrote:
>
>> On Mon, Mar 1, 2010 at 22:28, Alexander Klimetschek <aklimets@day.com>
>> wrote:
>> > Also it is optimized for trees
>> > with fine-granular content (eg. a page in a CMS), not for arbitrary
>> > sized subfolders with lots of binary content.
>>
>> Ah, forgot: have you tried your scenario with a FileDataStore? Using a
>> datastore avoids duplicate binaries in the storage, so there should
>> only be some overhead in hashing the files upon versioning. Not sure,
>> it might be that the versioning implementation internally temporarily
>> copies the files, which might be slow.
>>
>> Regards,
>> Alex
>>
>> --
>> Alexander Klimetschek
>> alexander.klimetschek@day.com
>>
>