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 lars@fazy.net designates
 74.125.82.179 as permitted sender)
MIME-Version: 1.0
Sender: lars@fazy.net
In-Reply-To: <518904CE.9010206@liip.ch>
References: 
 <CAFzQOXhirmTAcYE6kthgW+UySYvrMukL-4y4U8Gk_p_Fy7xFFQ@mail.gmail.com>
 <CAFzQOXj0QqCX+54DWDwbx4wP6K_RqXQ+uW+o96JNKKqyfyGi7Q@mail.gmail.com>
 <518904CE.9010206@liip.ch>
From: Lars Janssen <lars-listmail@ukmix.net>
Date: Thu, 9 May 2013 18:01:12 +0100
Message-ID: 
 <CAFzQOXibSENOBvVgHbRDHF06Zn1rW2DJpR5=V4tLfPxTZG8ePQ@mail.gmail.com>
Subject: Re: Preview workflow based on workspace clone/node update
To: users@jackrabbit.apache.org
Content-Type: multipart/alternative; boundary=047d7bd91f409a612c04dc4c007c

--047d7bd91f409a612c04dc4c007c
Content-Type: text/plain; charset=ISO-8859-1

Hi David,

Thanks *very* much for looking into this and sharing your findings.

* cloned nodes share the version history, so checkins in either
> workspace go into the same history.
>

This is good to know, although am I right in thinking it shouldn't affect
my current workflow (make changes in a "preview" workspace, clone/update to
"published")? Note that I'm not currently using versioning, but intend to
soon.

My understanding then is that clone and update should work the same for a
node with mix:versionable as for one without (leaving children aside for a
moment). It's only when you use checkin, restore etc. that the shared
version history becomes apparent.

* when updating, jackrabbit at least is using this version history to
> destroy as little information as possible. so if a field was updated in
> the updating workspace but not in the one we update from, the changed
> field is kept.
>

I'm not sure if I understand this. Presumably for non-versionable nodes,
this simply doesn't apply. For versionable nodes, are you saying the update
operation looks at the version history and doesn't just compare the base
nodes in both workspaces?

Imagine this scenario:

- Create a (mix:referenceable, mix:versionable) Node N in workspace A
- Create a new version of N (checkin), so you have version 1.1 and the base
version (I think we can ignore the root version)
- Clone N into workspace B, giving a node N' in that workspace
  (look at the version history for either N or N', and you'll see the same
original version 1.1)
- Change a property of N, change the same property of N' to a different
value
- Now try to update N' with the changes from N... what happens?

That last part is what I don't understand. I haven't tested it, but I
thought that the changes from N would overwrite any changes in N'. Are you
saying that actually the version history is used somehow?

* jackrabbit currently checks children if they are mix:versionable and
> if so, skips them. so you could model your content as versionable for
> things that you do want to synchronize separately.
> it should be mix:simpleVersionable instead of mix:versionable, i think
> jukka created a patch for that, but this will at best come in the next
> 2.6 release. i *think* phpcr-odm is currently using
> mix:simpleVersionable, but i could be wrong here.


Do you mean that Jackrabbit skips mix:versionable nodes when performing an
update? Suppose I have nodes like this, where * means the node is
versionable:

/page*
/page/block-1
/page/block-2
/page/sub-page*
/page/sub-page/block-1
/page/sub-page/block-2

If I update "/page" from workspace A to workspace B, then should only the
following nodes be updated?

/page*
/page/block-1
/page/block-2

I have tried testing this using the phpcr-api-tests suite, with
mix:versionable and mix:simpleVersionable, and in both cases any changes to
"/page/sub-page" are copied across when I update "/page".

Thanks,

Lars.

--047d7bd91f409a612c04dc4c007c--