One additional note: It would be fine to record the "lineage" of the new version-history created by the copy, by adding a property to the version-history that is a reference to the version from which that new version-history was created. We could call it the "copy-source" property. This copy-source property would give folks all the information they need, without violating the change-set
invariant. Someone that wants to reconstruct the "cross-copy history", could do so by traversing both predecessor references and copy-source references. If we want to doubly link the data structure, we could add a "copy-destination" reference, that is the inverse of the copy-source reference. Cheers, Geoff "David Nuescheler" <[EMAIL PROTECTED]> wrote on 03/03/2006 04:43:22 AM: > 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
