hi carlos, thanks for the insight.
> When you copy a versionable node in jackrabbit, is its version history > reset? I mean the new node starts with a fresh version history? correct. not just in jackrabbit but in jcr in general. the node will get a new uuid and therefore will get a new versionhistory. > In subversion the version history of the new node (after a copy or move) > starts with the version of the source node at the time of the copy. move of course works the same way in jcr. copy doesn't. > Thus > when you examined the version history of the copied node, you see the > versions in the new place plus the versions when it was in the old > place. I believe that's why it's not necessary to copy the whole version > history, it's shared by both nodes, up to the time of the copy, and the > fact that it was copied it's also recorded. hmm... i am not sure i can see all the consequences of sharing a version history between two nodes within the same workspace. for example cloned nodes in different workspaces of course share one version history. while i am still looking for a good reason why version histories in general are not copied (at least in my experience) in any config management environment, i believe that copying a version history (with all its original timestamps) would be sort of "lying" about what happend to a node in the past. regards, david
