Hi Tobias and all,
thank you very much for your support. Your help has been very precious,
everything is clear now on my side, and I see that Jackrabbit 2.0 implements
exactly what described in JCR 2.0. I will structure my repository
accordingly.
Regards,
Davide
On Fri, Mar 26, 2010 at 9:47
On Thu, Mar 25, 2010 at 18:36, Davide Maestroni
davide.maestr...@gmail.com wrote:
Hi Alex,
sorry for the late reply, I've been out during the past weeks.
Actually I'm not sure how to write a unit test for Jackrabbit, beside I am
using it through Sling and Jetty, so I cannot provide you the
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
• C has an OPV of COPY,
a copy of the entire subgraph rooted at C
On Fri, Mar 26, 2010 at 3:23 PM, Davide Maestroni
davide.maestr...@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
Hi Alex,
sorry for the late reply, I've been out during the past weeks.
Actually I'm not sure how to write a unit test for Jackrabbit, beside I am
using it through Sling and Jetty, so I cannot provide you the whole code
since the architecture I have implemented is quite complex and articulated.
Hi Alex,
what I see is that each time the file D (along with its data) is copied in
the new version of node A. I understand that no diff mechanism is employed
when applying COPY opv, so it is ok that the node B and all its properties
are copied in the new version of A (since B is not versionable
Hi Alex,
I did another test removing the node B, so the structure became like this:
A (mix:versionable, nt:unstructured)
^
|
C (mix:versionable, nt:unstructured)
^
|
D (nt:file)
^
|
E (nt:resource)
When I created a version of A, with the same number of files
On Thu, Mar 4, 2010 at 10:52, Davide Maestroni
davide.maestr...@gmail.com wrote:
Hi Alex,
I did another test removing the node B, so the structure became like this:
A (mix:versionable, nt:unstructured)
^
|
C (mix:versionable, nt:unstructured)
^
|
D (nt:file)
^
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)
^
|
B (nt:unstructured)
^
|
C
On Wed, Mar 3, 2010 at 22:02, Davide Maestroni
davide.maestr...@gmail.com wrote:
...what I expect when versioning the node A is that D and E are
not copied, but it is not what I observe.
What exactly do you observe?
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetsc...@day.com
On Mon, Mar 1, 2010 at 19:31, Davide Maestroni
davide.maestr...@gmail.com wrote:
In my repository I have a vesionable root node with a few child nodes, each
containing a lot of files (let's say more than 200). I set the VERSION rule
for each child of the root node, which are in turn versionable
On Mon, Mar 1, 2010 at 22:28, Alexander Klimetschek aklim...@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
12 matches
Mail list logo
