hi paco, > > i think the version history is not affected if you make changes > > to your node types. > This is not always true. I'have added an "user comment" property to the > versioned node, so the applications expect to see this property in the > versioned nodes. The old repository do no have this property, so will > fail with the actual modification. well, generally i think it is important to distinguish between "versions" and "versionable nodes". if we are talking about old "versions" of the node then these are considered immutable in the repository. this is an important design principle and thats why the concept of a frozen node what introduced in jcr. so an application should be able to deal with the fact that over the course of a version history the nodetype definition may have changed, hence the "frozen node".
> > generally the version store is implemented as a workspace so you can > > just copy the version store on to your new repository, but you need > > to make sure that the uuid's (and version property) of the nodes in > > your workspace(s) are preserved so they match the uuid's in the > > version store. i would probably use a system view export to make > > sure of that. > > does that work for you? > I've benn trying to export / import "/jcr:system/jcr:versionStorage" > with no results :( that's not what i meant. you can copy the underlying version store on an fs or rdbms level, but as far as i understand you would like to export, modify and then re-import the version store. as far as i am concerned due to the immutable nature of versions i think this is probably not even a sustainable use case that we would like to cover in jcr. as mentioned above, the concept of the frozen node has exactly been introduce to accomodate nodetype changes without having to modify the version store. regards, david
