My suggestion is that you make versionable each child node and only when you change it. If you want to return to a previous state, simply remove the child node that you want (if it was not modified) or restore a previous version(if it was modified).
2009/1/21 Alexander Klimetschek <[email protected]> > On Wed, Jan 21, 2009 at 8:21 PM, Micah Whitacre <[email protected]> > wrote: > > Hmm that clarifies and explains what I am seeing and why I am seeing > > that behavior. However I'm assuming if I were to alter that property > > (to what value I'm not sure) I would lose the ability to retrieve the > > child nodes at the time the version was created from the frozen node? > > So code like this would no longer work: > > > > Version version = node.getBaseVersion(); > > Node versionNode = version.getNode("jcr:frozenNode"); > > NodeIterator it = node.getNodes(); > > //it would contain all my child nodes. > > > > Wouldn't that negate the benefit of having versioned nodes if I > > couldn't retrieve the state of the repository for a certain version? > > I guess that Jackrabbit's versioning isn't optimized for that use case > yet. Most versioning use cases are on a per node incl. all child nodes > basis, ie. the whole subtree is versioned once upon a checkin, while > the structure above that node is not versioned. This is typical for a > CMS scenario, where you do not version the structure of your site, but > version individual pages. In your case, however, the main point is in > versioning the rather large structure of child nodes. > > BTW, I am wondering why you first do a node.checkin() and then > child.checkin() in the code you've posted. Shouldn't it be the other > way around? > > Regards, > Alex > > -- > Alexander Klimetschek > [email protected] >
