Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of tripod@day.com designates
 207.126.148.85 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <8ea1ff9e1003260723t513b30f1g89b7920c98c1856e@mail.gmail.com>
References: <8ea1ff9e1003011031i71527587qd8a5e327292ad2b0@mail.gmail.com>
	 <c3ac3bad1003011328u12732ae8v33a092d474212f1a@mail.gmail.com>
	 <c3ac3bad1003011331xb4cbf63hd5575161d6894946@mail.gmail.com>
	 <8ea1ff9e1003031302t343ebae8n404dca7073de580c@mail.gmail.com>
	 <ffd6aaa91003260605u3cbd6319vcf5a44e51ee50658@mail.gmail.com>
	 <8ea1ff9e1003260723t513b30f1g89b7920c98c1856e@mail.gmail.com>
Date: Fri, 26 Mar 2010 21:47:12 +0100
Message-ID: <ffd6aaa91003261347w7b3a52f9qa74438c17732f40f@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

On Fri, Mar 26, 2010 at 3:23 PM, Davide Maestroni
<davide.maestroni@gmail.com> wrote:
> Hi Tobias,
>
> what you wrote is perfectly right, however if you look at
> http://www.day.com/specs/jcr/1.0/8.2.11.2_VERSION.html (I have just
> copy/pasted from there), the versioning process described is a bit
> different.
> I really don't know if there is a bug or not, I'm just trying to clearly
> understand how the versioning works in Jackrabbit and which is the expect=
ed
> behavior in each case.
> Since it looks to me that JCR 1.0 and JCR 2.0 say slightly different
> things (but with huge impact) and I have observed the same behavior using
> Jackrabbit 1.0 and Jackrabbit 2.0, I am bit confused about how things sho=
uld
> work.
> If you say that the versioning of a whole sub-tree depends only on the ch=
ild
> node, and not on all its descendants, I am perfectly fine with that, I ju=
st
> want to be sure that what I see is correct, and my understanding of the
> specifications is correct as well.
yes. jcr2.0 is far more precise about the versioning. if i remember
correctly, in jackrabbit 1.0 the behavior was different, indeed.
jackrabbit 2.0 implements the versioning as described in jcr2.0

regards, toby

>
> Thanks,
>
> Davide
>
>
> On Fri, Mar 26, 2010 at 2:05 PM, Tobias Bocanegra <tripod@day.com> wrote:
>
>> 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 =A0 =A0 =A0 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=3DVERSION:
>>
>> 3.13.9 Versionable State
>> [...]
>> 6. For each child node C of N where:
>> =95 =A0 =A0 =A0 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*, howev=
er
>> the
>> > recursive copy terminates at each versionable node encountered further
>> below
>> > in the subtree, at which points the standard *VERSION* behavior is aga=
in
>> > 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.c=
om
>> >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
>> >>
>> >
>>
>