After further testing, I concluded that the workaround does not work. The problem is that when restoring a node to a specific version, some of the subnodes are not restored properly.
I will try to create a unit test to reproduce this issue, Could this be a persistence specific issue? --zoly On Aug 26, 2010, at 4:06 PM, zoly farkas <[email protected]> wrote: > My workarroud to work to get the behaviour I expect is: > > when i need to restore to version X I do: > > restore("1.0"); > restore("X"); > > this seems to restore the node to the proper state. > > This look more and more like a bug... > > --zoly > > > ----- Original Message ---- > From: zoly farkas <[email protected]> > To: [email protected] > Sent: Thu, August 26, 2010 3:27:07 PM > Subject: question about jackrabbit 2.1.1 versioning unextected behavior > > I have a Nodetype > > > [my:Config] > mix:versionable > - subConfigs (my:SubConfig) multiple > > > I created a node: /Configuration of type my:Config > > and I have added subConfigs to this node, > > vms.checkout("/Configuration"); > Node config = session.getNode("/Configuration"); > config.addNode("subConfigs", "my:SubConfig"); > session.save(); > vms.checkin("/Configuration"); > > after doing a lot of aditions I have got to: revision 1.57 of /Configuration > with 10 subConfigs > > I do a vms.restore("1.56") and a vms.restore("1.57") and when I list list > subConfigs I have 9 subConfigs. > > however when I do a vms.restore("1.1") and a vms.restore("1.57") and when I > list > > list subConfigs I have 10 subConfigs. > > can somebody explain to me what is going on ? > > thank you > > --zoly > > >
