I just wanted to follow up with an answer to my previous question.
I ended up working around this by performing a system view export on the frozen node with a custom ContentHandler to manipulate the output to something that can be imported as a non-frozen node. The custom ContentHandler changes the name of the node to the actual name rather than jcr:frozenNode, changing the uuid to the value of the frozenUuid, and removing the fields that are unnecessary. It works however if anyone can think of a better solution that would be appreciated. Thank you, Bob On 6/18/07, Bob Wieler <[EMAIL PROTECTED]> wrote:
Hi, I need some help implementing some functionality that utilizes the merge capability of JCR/Jackrabbit. I have an application where users use their own personal workspace to add referenceable nodes to a parent node and commit the changes. At a later time (after making a number of these changes) they can merge their own personal workspace with another workspace where all of the changes from all of the users of the system will be contained. The problem that I'm having right now is dealing with the conflicts that could occur as a result of the merge operation. If two users edit the same parent node and they both try to merge those changes, the second user will (obviously) fail. If the change the second user made was to add a new child node with a specific UUID (referenced elsewhere), I will need to manually merge that change into the parent. Unfortunately when I create the new child node, I'm not able to specify a UUID for that new child - a UUID that is referenced elsewhere in the workspace. How do other people deal with merging workspaces and dealing with conflicts? I do know that there is an addNode method on NodeImpl that takes a UUID but I was hoping to be able to do this without exposing Jackrabbit specific functionality. I assume that the writers of the JCR specification thought of how the merging would be done but I can't figure out an easy way of dealing with it. Thanks, Bob
