You can always do it programmatically (albeit I do recognize it's a
PITA...), something like this (you'll need a connection to both old and new
repo), in pseudo-code:
while (there's content) {
revhistory = get_revhistory_for_content_on_old_repo();
while (revhistory.hasNext()) {
revision = revhistory.next();
contentToCopy = read_frozen_node_for_rev(revision);
write_on_new_repo_creating_a_new_revision(contentToCopy);
}
}
HTH
On Thu, May 14, 2015 at 5:46 PM, Flavel Heyman <[email protected]
> wrote:
> I noticed this statement from some random guy on the internet:
> http://www.liferay.com/community/forums/-/message_boards/message/2108515
> excerpt: "Note that the export file will have all your docs and also
> revision history, but there is no way to import back all your revision
> history from an export file (it is not part of the jcr specifications)."
>
> So if that is true then, guess I’m stuck recreating the versions manually,
> *slow clap*. That makes sense.
>
>
> >****Part 1:
> >
> >I receive an exception while trying to import the ³/jcr:system² node into
> >³/³: javax.jcr.ItemExistsException: Node with the same UUID exists:node
> >/jcr:system
> >
> >When I run through debug mode the node IDs are not equal causing
> >Jackrabbit to throw the exception:
> >existing.getId() = "deadbeef-cafe-babe-cafe-babecafebabe²
> >id = null
> >
> >
> >
> >My simple import code:
> >
> >ByteArrayOutputStream out = new ByteArrayOutputStream();
> > session.exportSystemView("/jcr:system", out,
> false, false);
> > System.out.println("WAIT: "+ new
> String(out.toByteArray()));
> >//Insert a breakpoint here to modify data before replacing the current
> >data, simple test
> >
> > InputStream in = new
> ByteArrayInputStream(out.toByteArray());
> > session.importXML("/", in,
> >ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING);
> > session.save();
> >
> >
> >
> >Jackrabbit code in SessionImporter (line 377 for Jackrabbit 2.6.5 (my
> >current version) (also exists for the same line in 2.10.0¹s version)):
> >
> >if (!(existing.getId().equals(id)
> > && (uuidBehavior ==
> >ImportUUIDBehavior.IMPORT_UUID_COLLISION_REMOVE_EXISTING
> > || uuidBehavior ==
> >ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING))) {
> > throw new ItemExistsException(
> > "Node with the same UUID exists:" +
> >existing);
> > }
> >
> >
> >I would venture to say the Node with the same UUID does not exist
> >(assuming ID is equivalent to the UUID being reference by the errorŠ).
> >The error description should be a bit different, or add more information.
> >The XML I¹m trying got import is about 5,624 lines long, but I doubt
> >people want to receive that in their inbox.
> >
> >****Part 2:
> >
> >When I import the ³/jcr:system² node into a subfolder (like /z,
> >nt:unstructured) it only brings in the 2nd level of children from
> >³/jcr:system² (jar:versionStorage, jar:activities, jcr:nodeTypes). It
> >doesn¹t bring in any versions! The export has all the data but the import
> >is deleting the important information. Some configuration for my current
> >system:
> >Repository.OPTION_XML_IMPORT_SUPPORTED is true
> >
> >In my repository XML I have the following that helps with importing the
> >ACLs:
> ><Import>
> > <ProtectedNodeImporter
> >class="org.apache.jackrabbit.core.xml.AccessControlImporter"/>
> > </Import>
> >
> >
> >
> >By default shouldn¹t Jackrabbit just import everything? Start with being
> >able to import everything and narrow scope through configuration. At
> >least then devs would be able to use expected features easily. I would
> >prefer to just export ³/³ and import into ³/³, but:
> >javax.jcr.nodetype.ConstraintViolationException: Unexpected node type
> >{internal}ACL. Should be rep:AccessControl or rep:PrincipalAccessControl.
> >
> >
> >Sincerely,
> >-Annoyed I¹m still using this.
> >
>
>
--
Fabián Mandelbaum
IS Engineer
