Thanks very much for the feedback. Hi Jukka - the system view export does include jcr:baseVersion. However, when I stepped through the import code the very last thing it does is set jcr:baseVersion to rootVersion at which point the old value for baseVersion is lost. It seems like that could actually be the desired behavior so I wanted to discuss before filing a bug. I was thinking if you wanted to export and then import into a new workspace, you'd probably want to have jcr:baseVersion set back to rootVersion so your next check in results in a new branch. What do you think?
Assuming it's a bug, having importXML set jcr:baseVersion back to whatever it was when it was exported would probably work well for this particular undo/redo problem we're having. I'm just concerned that it would change the current expected behavior of export/import. thanks, rob On Mon, May 5, 2008 at 2:41 AM, Jukka Zitting <[EMAIL PROTECTED]> wrote: > Hi, > > On Thu, May 1, 2008 at 10:36 PM, Rob Esposito <[EMAIL PROTECTED]> wrote: > > The other approach we've been using is to store the state of the node > just > > before deletion using Session.exportSystemView and to bring it back > using > > Session.importXML. The problem with this method is that, after an > > importXML, the restored node is checked out with base version set to > > rootVersion. The expectation is that the user will have to check this > node > > back in and the version history will branch each time this happens. > > Hmm, the system view export should contain the jcr:baseVersion > property which the import should be able to connect back to the > correct entry in the version history. Please file a bug if it doesn't. > > BR, > > Jukka Zitting >
